Los sitios web se crean en el contexto {context} de una organización, o al menos de una persona, que tiene un objetivo y recursos para crearlo. Durante la fase de análisis es probable que usted celebre una cantidad copiosa de reuniones con el cliente y los usuarios. En ellas realizará preguntas para comprender el contexto del problema a resolver. Conviene preparar una lista inicial de preguntas, como los ejemplos de la Tabla 1 (Rosenfeld et al., 2015).

Si la organización es muy grande, indague primero quién es la persona idónea para responder cada pregunta que usted tenga. Trate de mantener reuniones informales con pocas personas (5 o menos). Anote las respuestas o grabe la sesión con consentimiento previo. La reunión informal se recomienda con el fin de establecer confianza {rapport} con las personas de la organización, y así obtener respuestas sinceras, sobre todo a las preguntas difíciles pero necesarias para el nuevo sitio web. Haga las preguntas que necesite sobre la marcha y puede permitir a los interlocutores vagar un poco, lo cual le permitirá conocer más sobre el contexto (Rosenfeld et al., 2015).

Durante las reuniones descubrirá documentos afines como los listados en la segunda columna de la Tabla 1. Si la organización ya cuenta con un sitio web, es valioso averiguar en qué medida éste ayuda o no a la organización a alcanzar su misión, visión, y objetivos. El Ejemplo 1 muestra el análisis de contexto del proyecto de ejemplo Bingo, el cual es un trozo de su archivo README.md.

Un sitio web es un mecanismo tecnológico que permite a las personas comunicar información entre sí. Esta información es codificada en medios digitales, y al resultado se le llama contenido {content}. En la fase de análisis de contenido, su objetivo es determinar qué información se intercambiará entre las personas a través del sitio web, y las cualidades que deberá tener.

El análisis de contenido revisará los trozos de información existentes en la organización, con el fin de identificar los tipos de contenidos que tienen sentido formen parte del sitio web (Rosenfeld et al., 2015), como páginas estáticas o aplicaciones. Para cada contenido es apremiante cuestionarse sus cualidades, que además le permitirá una mayor comprensión del sitio web a elaborar. La Tabla 2 muestra ejemplos de algunas cualidades, y preguntas a realizar sobre el origen de los contenidos, y su destino en el sitio web.

El análisis de contenido de la organización es un trabajo arduo pero no infinito. Dependiendo de los recursos e intereses de la organización, puede ser un muestreo informal, una auditoría detallada, o una mezcla de ambas (Rosenfeld et al., 2015). Es probable que al inicio del análisis de contenidos sienta que hay muchos tipos de contenidos distintos, pero conforme avance, los contenidos se irán clasificando en los tipos que ya haya identificado. Para cada nuevo tipo de contenido documente sus cualidades (como las de la Tabla 2). Mientras lo hace, notará relaciones entre los tipos de contenidos, o si es un tipo ya existente. Usted puede detener el análisis de contenidos cuando ya no encuentre tipos de contenidos nuevos, o los contenidos no le provean conocimiento nuevo sobre los tipos existentes (Rosenfeld et al., 2015).

Si la organización ya cuenta con un sitio web que quiere mejorarse o desecharse, es una oportunidad para reutilizar contenido y obtener requerimientos. Con ayuda de una herramienta automatizada puede crear un mapa de contenido {content map}, que es una representación visual del contenido existente y sus relaciones (Rosenfeld et al., 2015). Estas representaciones pueden discutirse con miembros de la organización para determinar qué contenido debería o no mantenerse o mejorarse en el nuevo sitio web. El Ejemplo 2 muestra un trozo del archivo README.md con los tipos de contenidos identificados en el proyecto Bingo.

Cuando existen sitios web similares al que se quiere construir, sea de la organización o de la competencia, conviene estudiarlos y evaluarlos. Su estudio permite obtener una lista de características que desean mantenerse o mejorarse en el nuevo sitio web. La evaluación permite obtener medidas cuantitativas o cualitativas que forman una línea base con la que se puede medir y comparar nuevo sitio web (Rosenfeld et al., 2015). Ejemplos de estas medidas son la cantidad de tiempo que tarda un visitante en encontrar un trozo de información relevante, o la eficacia con que logra resolver alguna tarea con el sitio web existente.

Una forma de estudiar un sitio web existente es a través de una evaluación heurística {heuristic evaluation} (Rosenfeld et al., 2015). Esto es, al menos un(a) experto(a), idealmente ajeno(a) a la organización, critica la arquitectura de la información, el diseño gráfico, la experiencia de usuario, o algún otro aspecto del sitio web actual siguiendo un conjunto de principios o prácticas recomendadas llamadas heurísticas. Si se cuenta con varios expertos(as), éstos deliberarán en busca de un consenso. Los expertos harán visible un conjunto de supuestos que el sitio web actual cumple o no, y sugerencias de cómo mejorarlo, las cuales servirán como requerimientos para el nuevo sitio web.

Si usted construye un sitio web que confunde a sus usuarios, ellos simplemente no lo usarán o acudirán a la competencia (Robertson, 2016). Los daños de un sitio que no satisface las necesidades de sus usuarios van más allá de los altos costos de creación, y encima de re-diseño. El prestigio de la organización está en riesgo, sin listar otros perjuicios a sus clientes y empleados.

Durante el análisis de los usuarios averigüe, potencialmente con su cliente, quiénes usarán su sitio web. Si la tiene una lista de personas físicas, clasifíquelas en roles de usuario. Su objetivo es identificar para cada rol, cuáles son sus necesidades o deseos de información, y cómo piensan usar el sitio web para satisfacerlas. El Ejemplo 3 lista en una tabla los roles de usuarios identificados en el proyecto Bingo.

Si no puede interaccionar directamente con sus usuarios, pero sí comunicarse con ellos, puede pedirles que le respondan una encuesta con preguntas como las listadas en Tabla 4 (adaptadas de (Robertson, 2016)). Si usted puede interaccionar con los usuarios identificados, lo cual es más probable si laboran para una organización, puede observarlos en su contexto para identificar cómo resuelven sus necesidades de información con los recursos que la organización actualmente dispone, en especial si cuenta con un sitio web. Esta oportunidad le permite alcanzar un mayor nivel de comprensión a través de métodos como personas.

Personas o personajes (del inglés, personas) es un método de análisis usado en interacción humano-computador (HCI) que describe los roles de usuario y sus necesidades representados por al menos un miembro ficticio del rol. Identificar personas que usan el sitio web convierte al análisis de usuarios en un proceso menos abstracto, más humanizado y detallado. El equipo web crea al menos un personaje para cada rol de usuario como si fuese una persona física real que va a usar el sitio web. A esta persona se le dan las características como las listadas en la Tabla 5 (Brown, 2011). No se recomienda documentar personas físicas reales, sino crear personajes ficticios a partir de ellas. Recuerde que un personaje representa un rol de usuario, y por tanto, se construye a partir de características comunes de las personas físicas que representa. El Ejemplo 3 muestra personas de ejemplo para el proyecto Bingo.

Una vez que haya completado el análisis de usuarios y contenidos (Sección 1.4.2), conviene crear una matriz de roles de usuario contra contenidos del sitio web. En las celdas se anotan las acciones que los usuarios pueden realizar con dichos contenidos, tales como crear, y consultar, editar o eliminar (los propios o de los demás). El Ejemplo 3 muestra un ejemplo de esta matriz para el proyecto Bingo.

Durante la fase de análisis del sitio web (Figura 1) usted elabora documentos que describen el contexto, los usuarios, y los contenidos que intercambiarán en el sitio web. Es recomendable que usted pruebe estos artefactos conforme los produzca. Sin embargo, es fundamental probarlos para determinar si es propicio avanzar a la siguiente fase del proceso de resolución de problemas.

Para probar los documentos de análisis, distribúyalos entre los clientes, usuarios, o interesados en el sitio web. Solicíteles leerlos y criticar lo que no es claro o correcto. Pregúnteles qué es necesario en el sitio web que haga falta en el documento. Cada deficiencia que se detecte se hará en el momento idóneo, pues su corrección requerirá el mínimo de esfuerzo. De pasar a las fases posteriores, un error será más costoso de corregir y sus efectos no son sólo nocivos para los clientes, sino también para el prestigio del equipo web.

El mapa del sitio web {site map} es una representación visual de la estructura de un sitio web. La estructura del sitio web {website structure} se refiere a las relaciones que existen entre los contenidos o páginas web que componen al sitio (Brown, 2011). El mapa del sitio es un diagrama que facilita la comprensión del sitio y ayuda enormemente en el proceso de toma de decisiones. Conviene mantenerlo actualizado conforme el sitio cambia su estructura, lo cual es normal a través de su ciclo de vida.

El término "mapa de sitio" también se usa en otros contextos para referirse a una página del sitio web cuya función es listar las páginas más relevantes para los visitantes humanos, o a un archivo en notación XML (sitemap.xml) con detalles importantes para motores de búsqueda que no se pueden inferir directamente de la navegación del sitio. En este material el término hará referencia al diagrama que muestra la estructura del sitio web con fines de diseño.

Un mapa de sitio es un grafo que representa con nodos el contenido del sitio y con aristas las relaciones de pertenencia o navegación (hiperenlaces) entre estos contenidos. Contenido {content} es cualquier trozo de información enlazable, como una página web, un video, o una imagen (Brown, 2011). Para un sitio web documental, los nodos del mapa serán páginas web que contienen documentos. Para una aplicación web los nodos del mapa serán pantallas. Normalmente los sitios web modernos se componen de una combinación de ambos tipos, es decir, de páginas web documentales y páginas web que son pantallas de una aplicación web.

Un mapa de sitio documental trata de resaltar jerárquicamente la pertenencia o navegación entre los contenidos, donde un nodo hijo es un contenido que pertenece o forma parte del contenido padre (Brown, 2011). Relajando algunas restricciones, un organigrama cumple con estas características. Quizá esto explique por qué muchos sitios web se han construido reflejando la estructura de su organización. La Figura 4 muestra un extracto del organigrama institucional de la Universidad de Costa Rica.

La experiencia indica que la estructura organizacional pocas veces resulta natural para los visitantes (Brown, 2011). Por ejemplo, si se usa el organigrama de la Figura 4 como mapa de sitio, su navegación constaría de tres menúes, los dos primeros con una entrada para el "Tribunal Electoral Universitario" y la "Contraloría Universitaria" respectivamente, y el tercer menú para la "Rectoría" estaría sobrecargado de entradas y sub-menúes. Siguiendo esta navegación, un estudiante de computación tendría que realizar cinco accesos, desde "Rectoría", "Vicerrectoría de Docencia", "Área de ingeniería", "Facultad de Ingeniería", para llegar a la "Escuela de Ciencias de la Computación e Informática".

La Figura 5 es un extracto del mapa de sitio real de la Universidad de Costa Rica en abril de 2020. Aunque la estructura sigue siendo jerárquica, la página inicial se dibujó hacia el centro del diagrama y se enlazó con las secciones principales del sitio web.

De las relaciones de pertenencia en un mapa de sitio puede inferirse parcialmente la navegabilidad del sitio web, dado que es normal proveer enlaces que permiten al visitante desplazarse desde la página principal hacia las hojas o viceversa. Es parcial porque otros mecanismos como buscadores internos o externos también posibilitan llegar a los contenidos directamente (Brown, 2011). Por ejemplo, en el mapa de la Figura 5, para llegar a la "Escuela de Ciencias de la Computación e Informática" el estudiante podría usar el buscador o el directorio, ambos en el primer nivel estructural, y por tanto, disponibles en todas las páginas del sitio (aunque no en los subdominios).

A la circunferencia alrededor de la página principal se le llama nivel global de estructura {global structural level}, o primer nivel de estructura, porque resalta las secciones globales en que se divide el contenido del sitio. También se le dice nivel global de navegación {global navigation level} porque las secciones resaltadas en la circunferencia conforman el primer nivel del menú de navegación, el cual está presente en todas las páginas del sitio web. Los contenidos en la circunferencia de la Figura 5 están presentes en todas las páginas del sitio web de la Universidad de Costa Rica (UCR), sea como enlaces o controles en el encabezado, pie de página, o la barra de menú. La Figura 6 presenta una captura de pantalla del menú compuesto de los nodos cuyos rectángulos tienen más altura en la circunferencia de la Figura 5.

Los nodos externos directamente conectados a los que están ubicados en la circunferencia conforman el segundo nivel de estructura o navegación. Normalmente aparecen como ítems en el menú que les corresponde, como las siete entradas del menú "Docencia" en la Figura 6. Usualmente un mapa de sitio presenta hasta un tercer nivel de estructura o navegación si se dispone de espacio. Si necesita más niveles, considere en subdividir el diagrama. (Brown, 2011)

En un mapa del sitio un contenido se representa con un rectángulo, cuadrado, o círculo, que encierra una etiqueta que lo identifica. En ocasiones es difícil precisar una etiqueta significativa o, por el contrario, se debe escoger entre varias candidatas. En tal caso anótelas como tentativas ya que en la fase de prueba del diseño servirán para discusión. (Brown, 2011)

Es común la presencia de plantillas en los sitios web. Las plantillas de páginas web {web page templates} son páginas web con campos ideados para que un programa de computadora los llene con contenido extraído de bases de datos u otras fuentes. Cada vez que este "relleno" ocurre, se genera una página web. De esta forma, una plantilla puede producir una cantidad arbitraria de páginas web, lo que se representa en el mapa del sitio como una pila de documentos (Brown, 2011). El Ejemplo 4 ilustra algunas plantillas del proyecto Bingo.

No existe una notación estándar para los mapas de sitio. Aspectos de apariencia de los nodos y sus relaciones, tales como formas, tamaños, bordes, rellenos, tipografías, capturas de pantalla, miniaturas, colores, transparencias, patrones, brillo, y decoraciones, pueden usarse para comunicar otros detalles útiles sobre el sitio web. Por ejemplo, la apariencia de los nodos puede ayudar a distinguir:

En cualquier caso, asegúrese de proveer una leyenda en el diagrama, usar pocos estilos, y mantener la consistencia. Por ejemplo, en la Figura 5 se usaron formas y colores para distinguir las páginas del sitio oficial, de los subdominios, y de sitios web externos. A modo de sugerencia puede crear un "esténcil" {stencil} con sus convenciones y reutilizarlo en cada diagrama. Conviene indicar en el título del diagrama si representa a un sitio web existente o a un sitio web futuro. Es común agrupar varios nodos encerrándolos dentro de un rectángulo, porque las relaciones con el rectángulo aplican automáticamente a todos los nodos agrupados. (Brown, 2011)

En lugar de reflejar un organigrama, la información a comunicar en el sitio web ha de estructurarse para satisfacer las necesidades de sus usuarios, y por tanto, que les sea fácil de encontrar y comprender (Rosenfeld et al., 2015). El mapa del sitio resulta de organizar los contenidos recabados en la fase de análisis de contenidos (Sección 1.4.2) para satisfacer las necesidades recabadas en la fase de análisis de usuarios (Sección 1.4.3). El Método sugerido de elaboración de mapas de sitio documentales puede ayudar en esta labor.

Si la aplicación web es parte de un sitio documental, puede representarse en el mapa del sitio como un nodo más, y pueda que sea necesario un diagrama aparte para la aplicación web. En un mapa de sitio para una aplicación web, los nodos son pantallas de la aplicación, trozos de estas, u otros contenidos. Las aristas pueden representar la navegación que pueden realizar los usuarios entre las pantallas, o los contenidos que son mostrados en las pantallas. El Ejemplo 4 muestra esta labor para el proyecto Bingo.

Para probar mapas de sitio explique la estructura de su sitio web a un colega que conozca los requerimientos. Para probar con clientes espere a tener al menos bocetos, de lo contrario, los mapas serán muy abstractos para ellos. Explique el diagrama por partes, asociándolo con el sitio existente o futuro. Durante la sesión traten de determinar si la estructura es correcta, completa, y satisface las necesidades de los usuarios.

Las tres pruebas anteriores pueden realizarse de forma concurrente en un mismo recorrido por el diagrama. Es probable que realice varias pruebas. En cada nueva prueba resalte sólo los cambios nuevos.

Un esquema de página (wireframe o page schematic) es un boceto que ilustra cómo ubicar los contenidos en una página web con el fin de hacer clara la comunicación y satisfacer las necesidades de sus usuarios. Los esquemas de página lucen como las páginas web finales (Figura 8) que el usuario experimentará, pero con pocos contenidos y detalles de diseño gráfico, para que puedan producirse de forma muy rápida en la fase de diseño del sitio web (Brown, 2011). En el caso de las aplicaciones web, los esquemas de página son bosquejos {mockups} de las pantallas que ayudan a los desarrolladores web a idear la interacción con sus usuarios.

No es necesario elaborar esquemas para todas las páginas del sitio. Son candidatas aquellas que serán más visitadas y las marcadas como plantillas en el mapa del sitio. Normalmente un mismo esquema aplica para varias páginas del sitio, por lo que se consideran plantillas que al ser rellenadas con contenido y estilos producen las páginas web finales.

Eventualmente cada diseñador seguirá su propio método para elaborar bocetos. El Método sugerido de elaboración de esquemas puede usarse como punto de partida y que con la práctica puede refinarse y llegar a ser un proceso mecánico (hábito). Los resultados de este método serán aún mejores si es aplicado por un equipo web multidisciplinario. Si el equipo es grande puede aún subdividirse en equipos que realizan el proceso en paralelo y deliberan los últimos tres pasos (Brown, 2011).

Para dibujar un esquema se inicia con un rectángulo que representa la página web en diseño (véase la Figura 8(a)). Dentro de éste se dibujan más rectángulos que representan las regiones o áreas donde aparecerá el contenido en las páginas finales. La posición y tamaño de los rectángulos determinan parcialmente la prioridad que se quiere dar a los contenidos (Brown, 2011). Antes de llenar los rectángulos determine el nivel de abstracción y fidelidad (Figura 9) que tendrá el esquema.

La decisión de los niveles de abstracción y fidelidad, es decir uno de los nueve puntos de la Figura 9, depende de la audiencia a quien va dirigido el esquema de página. Si los esquemas son parte del diseño para el equipo de desarrollo, éstos preferirán esquemas abstractos que provean información sobre las variables y sus restricciones. Si los diagramas serán probados con usuarios finales, serán mejor comprendidos esquemas concretos y de mayor fidelidad. (Brown, 2011)

Debe considerar que entre mayor fidelidad del diseño gráfico, mayor será el tiempo de elaboración de un esquema, y de acuerdo al Método sugerido de elaboración de esquemas debería ser el último paso y sólo en caso necesario. Por lo tanto, se recomienda iniciar con esquemas a un nivel intermedio de abstracción y con baja fidelidad (punto resaltado en la Figura 9). Para este tipo de esquemas, en las regiones no se escriben contenidos, sino una etiqueta corta que indica su propósito, como "Pie del sitio" en la Figura 8(a). Las regiones en la página se pueden o no reutilizar en otras páginas del sitio, lo que permite clasificarlas en:

Se puede usar colores de relleno para distinguir regiones, siempre y cuando se apliquen consistentemente en todos los esquemas de página del mismo sitio web, por ejemplo, naranja para el encabezado del sitio, marrón para el pie de página, y así por el estilo. Esos colores son sólo para ayudar a distinguir las regiones en los diagramas, no quiere decir que sean los colores que tendrán en el diseño gráfico final. En cuanto al color del texto, se recomienda resaltar enlaces en azul, dado que las personas tienden a hacer esta asociación implícitamente, como se hizo en la Figura 8(b). Si los enlaces se encuentran dentro de texto, conviene además subrayarlos. (Brown, 2011)

Como se ilustra en el eje-x de la Figura 9, se puede variar el nivel de abstracción de los esquemas de página para adaptarlos a la audiencia. Si se considera al esquema de la Figura 8(a) en un punto intermedio (resaltado en la Figura 9), se puede incrementar el nivel de abstracción o de concreción. Un ejemplo es el esquema de la Figura 8(b) que tiene las mismas regiones del esquema Figura 8(a) con adaptaciones mixtas como las siguientes.

Si se elabora un esquema de página concreto para usuarios, es posible incluir información abstracta para desarrolladores, o viceversa, en la descripción del esquema. Esta estrategia tiene la ventaja de unir las ventajas de ambos mundos y evitar redundancia.

Los esquemas de página para aplicaciones web reflejan las pantallas con las que interacciona el usuario. Normalmente se componen de controles de los formularios web {widgets} como campos de texto y listas desplegables, así como otros controles que han ido surgiendo en el campo de la web como carruseles y mapas geográficos. Si usa un programa de diseño, es probable que disponga de figuras pre-diseñadas para representar controles de interfaz de usuario web.

Dependiendo de las necesidades de su sitio web, pueda que deba diseñar variaciones de un mismo esquema de página (Brown, 2011). Los siguientes son algunos ejemplos.

Los esquemas de página son ambiguos incluso aunque sean concretos y de alta fidelidad. Uno o más lectores frente a un esquema pueden interpretar diferentes escenarios de interacción. Por lo tanto, se recomienda documentarlos. Puede acompañar a cada esquema con detalles como los siguientes:

Mientras se lee una descripción puede ser difícil llevar el rastro de qué secciones del esquema hace referencia el texto. Una forma de facilitar el rastreo es anotar regiones en el esquema con números, y usarlos como referencia en el texto. El Ejemplo 5 muestra y detalla las pantallas para el proyecto Bingo Social.

Los mapas de sitio y los esquemas de página son vistas estructurales de la solución, pero limitan diseñar la riqueza del comportamiento dinámico de algunas aplicaciones web, en especial aquellas que constan de pocas pantallas cuyo contenido cambia dinámicamente de acuerdo a las interacciones con el usuario (Laubheimer, 2016). Esta sección presenta dos tipos de diseños, los wireflows y wirestates, que enriquecen los esquemas de página con aspectos del comportamiento de las aplicaciones.

Un wireflow es un formato de diseño que combina esquemas de páginas con elementos de diagramas de flujo para representar interacciones entre los usuarios y las pantallas de la aplicación. Puede pensarse como un diagrama de flujo que cambia sus pasos abstractos por esquemas de página que facilitan a los lectores comprender la interacción con el sistema (Laubheimer, 2016).

Un wireflow es un diagrama de flujo, y en consecuencia hereda sus propiedades. Un diagrama de flujo es una representación gráfica de un algoritmo, y por tanto, una secuencia finita y ordenada de pasos para resolver un problema. Un wireflow documenta un proceso, una tarea a realizar con el sistema. La cantidad de tareas que se puede realizar con un sistema puede ser numerosa, sin embargo, es habitual crear wireflows sólo para las tareas más comunes que realizarán los usuarios.

Los nodos en un wireflow son esquemas de páginas o trozos de ellas. En un nodo se resaltan las áreas de la pantalla con las que el usuario se espera que interaccione para lograr la tarea, por ejemplo, presionar un botón o ingresar un texto. Las áreas resaltadas se conectan mediante arcos dirigidos hacia otros nodos. Una relación entre dos nodos A y B indica que cuando el usuario interacciona con el área resaltada del esquema de página A, verá como resultado el esquema de página en B.

Los nodos A y B pueden ser pantallas distintas, o bien la misma pero en estados distintos. Si los nodos A y B son el mismo esquema de página, no es necesario incluir en B la información que no cambia de estado, sino que B podría ser un fragmento del esquema que resalta el cambio.

El arco dirigido entre dos nodos puede conectarlos de forma directa, pero no está restringido a ello. Un wireflow tiene todo el poder de un diagrama de flujo. Un arco podría pasar por una serie de pasos, entre los que se incluyen condicionales que pueden llevar a distintos destinos, por ejemplo, dependiendo de si el usuario ingresa un valor válido o no en un campo. El wireflow podría contemplar pasos no visibles para los usuarios como accesos a bases de datos, pero no se recomienda incluirlos si se van a realizar pruebas con usuarios finales.

Un wireflow narra el flujo de interacciones que los usuarios realizan para lograr una tarea, y un sistema puede ofrecer muchas tareas posibles. Si se usan como punto de partida para el diseño del sistema, los wireflows rápidamente pueden abrumar a los diseñadores en detalles. Un diagrama de flujo confiere mucho poder y control a los desarrolladores, ya que son una forma imperativa de resolver problemas. Otros tipos de diseños pueden ayudar a controlar el nivel de detalle a través de mecanismos de abstracción de más alto nivel, como las máquinas de estado.

Una máquina de estados finitos (finite-state machine), también conocido como autómata de estados finitos (finite-state automaton) es un modelo abstracto compuesto de un conjunto de estados, de tal forma que un programa sólo puede estar en un único estado en un tiempo dado. El programa puede pasar a otro estado ante la aparición de un evento o entrada. En la transición de un estado a otro, la máquina puede realizar operaciones procedimentales, pero no atender nuevos eventos.

Así como los wireframes se combinan con diagramas de flujo, también pueden combinarse con otros tipos de diseños. Al combinar wireframes como nodos de una máquina de estados finito, se obtiene un tipo de diseño al cual no se le ha otorgado un nombre, y en este material se propone el acrónimo wirestate.

Un wirestate tiene mayor nivel de abstracción que un wireflow gracias al paradigma de programación orientada a eventos. En un wirestate los nodos son wireframes que representan un estado de la aplicación web. Se puede pensar que mientras la aplicación web se encuentre en un estado, estará a la espera de eventos del usuario. Cuando el usuario produce un evento, el sistema reaccionará en respuesta realizando una transición hacia otro o el mismo estado. Al igual que los wireflows dos nodos podrían representar diferentes estados de la misma pantalla.

Las transiciones en un wirestate tienen dos partes rotuladas de la forma evento | reacción. El evento es generado por el usuario (por ejemplo, presionar un enlace) u otros sistemas informáticos (por ejemplo, la respuesta de un servicio web).

La reacción es una tarea que la aplicación web realiza en respuesta al evento. En el wirestate basta con darle un nombre la tarea, y ésta puede definirse luego mediante otros paradigmas. La tarea corresponde a una subrutina que se puede expresar posteriormente a través de un algoritmo (paradigma de programación procedimental), una función matemática (programación funcional), o un método de clase (programación orientada a objetos). De esta forma, un wirestate es un diagrama de muy alto nivel de abstracción que representa todos los estados del sistema, y cada transición ayuda a identificar algoritmos que el sistema deberá implementar.

Aunque un wirestate tiene similitudes con un diagrama de flujo, no lo es. Un autómata de estados finitos sólo consta de estados y transiciones, y éstas de eventos y reacciones. Se puede diferenciar el estado inicial y el estado final cuando el programa es ejecutado o termina su ejecución respectivamente. Lo demás no pertenece a un diagrama de estados. Los siguientes síntomas y heurísticas pueden ayudar a evitar el error común de tratar de combinarlos.

Todo artefacto elaborado en un proceso de resolución de problemas ingenieril debe ser probado. La mayoría de los artefactos resultantes de la fase de diseño del sitio web giran sobre las interfaces con las que interaccionarán usuarios. El propósito de la prueba de diseño es obtener retroalimentación de expertos (evaluación heurística) o de los usuarios (pruebas de usabilidad) de forma inmediata conforme los diseños son elaborados.

Normalmente las herramientas de diseño de esquemas de página {wireframing tools} también proveen funcionalidades de prototipado {prototyping tools}. Permiten proveer manejadores de eventos a potenciales interacciones de los usuarios, los cuales son apropiados para aplicaciones sencillas. Sin embargo, si la lógica del dominio es compleja, implementar un prototipo computacional tiene la misma complejidad que implementar el sistema final, lo que aleja la posibilidad de obtener realimentación temprana.

Se dispone de una riqueza de métodos e instrumentos de evaluación de interfaces de usuario que pueden ayudar a superar el problema descrito (Tullis & Albert, 2013). Un ejemplo de una técnica más rápida de elaborar es el caso de los prototipos en papel, que pueden evaluarse con una prueba de usabilidad.

Un prototipo en papel es una maqueta impresa o dibujada de la interfaz del programa. Aunque el prototipo no puede interaccionar directamente con un usuario, la persona desarrolladora puede "darle vida" al tomar el rol de la computadora. Se presenta a continuación un método con fines pragmáticos para evaluar la usabilidad o experiencia de usuario con prototipos en papel, que puede ser adaptado a conveniencia de acuerdo a las necesidades del proyecto.

Cada prueba de usabilidad que realice es una oportunidad para mejorar cualquiera de los artefactos realizados sobre el sitio web. La prueba podría hacer evidente una necesidad que no fue documentada durante el análisis de usuarios, o una pantalla o página que no fue considerada en el mapa del sitio ni en los esquemas de página, o un evento que no fue diagramado en la máquina de estados finitos. Es importante atender estos problemas antes de implementar la aplicación web, dado que es más barato y conveniente realizar modificaciones en diseños que en artefactos de software.

Los videos que grabe de las pruebas de usabilidad son una fuente rica de diseño de la solución. Al usted tomar el rol del sistema, las acciones que tuvo que realizar como respuesta a cada evento de usuario, son acciones que la aplicación web tendrá que realizar de forma automática. Mientras observa los videos, preste atención a estas acciones que realizó con los componentes en papel, y anótelos en las reacciones del sistema a los eventos del usuario en el wirestate.

Al realizar pruebas con usuarios de su prototipo obtendrá una sensación de seguridad al saber que su diseño realmente satisface sus necesidades o deseos. La teoría confirma que el tiempo invertido en diseñar y probar los modelos es inferior al tiempo que se tiene que invertir en reingeniería posterior {refactoring} (Rosenfeld et al., 2015), la cual encima genera productos de inferior calidad, más difíciles de mantener, y con los que da menos gusto trabajar.

En 1995 Microsoft ofreció el navegador Internet Explorer 1.0 para Windows 95, influenciado por el código licitado de NCSA Mosaic. La versión 2.0 fue gratuita incluso para uso comercial. Lentamente Internet Explorer fue tomando popularidad y mercado de Netscape, lo que generaría la primera guerra de navegadores.

Los ataques entre estos dos navegadores consistían en la inclusión de funcionalidades novedosas para atraer tanto usuarios como autores de sitios web. Por ejemplo, Netscape desarrolló JavaScript a finales de 1995, que un año más tarde sería imitado por el JScript de Microsoft, en la versión 3 de Internet Explorer. En esa versión particular, Microsoft incluyó una parcial implementación de las hojas de estilo en cascada {CSS, Cascading Style Sheets} sugeridas por el W3C pero aún no estandarizadas.

En 1997 Netscape fusionó su Netscape Navigator con otro conjunto de programas para correo electrónico, composición web, calendario, entre otros. Al suite se le llamó Netscape Communicator, nombre que serviría para confusiones. Microsoft integró Internet Explorer 4 con Windows y desalentó desde el sistema operativo el uso de cualquier otro navegador. Netscape no compitió contra esto, ni tenía sentido. Desde 1998 el 80% del mercado que tenía Netscape pasó a sumar el 96% que tenía Internet Explorer 5 en el 2002. La guerra de los navegadores había finalizado y también el rápido tren de innovaciones, tan evidente que Microsoft no volvería a hacer cambios significativos en su navegador desde el 2001 al 2006.

A inicios de 1998 Netscape liberó el código fuente de Netscape Communicator 4.0 en el proyecto Mozilla. La comunidad descartaría luego dicho código debido a su complejidad, poca modularización, al gran volumen de pulgas y otros inconvenientes resultado de la carrera por la innovación. La Fundación Mozilla empezó la construcción de un nuevo navegador modularizado hecho desde cero, compuesto de un motor de navegación {web browser engine}, al cual se le llamó, Gecko, y sería el motor de "renderizado" {rendering} de Firefox y el nuevo Netscape Communicator, que finalmente sería descontinuado a inicios del 2008.

La guerra de navegadores (aproximadamente de 1995 a 1998) también tuvo consecuencias muy negativas. Ambos, Netscape Navigator e Internet Explorer, ofrecían características novedosas incompatibles entre sí, es decir, dialectos de HTML distintos que provocaron que los autores de millones de páginas tuvieran que escoger por uno o por el otro. Era común ver imágenes indicando que el sitio se veía mejor con un navegador particular, incluso hasta de una versión específica.

Mientras tanto el proceso de estandarización avanzaba lentamente. En junio de 1994 Berners-Lee y otros autores proponen varios borradores de estandarización, y en noviembre de 1995 la Internet Engineering Task Force (IETF) aprueba el HTML 2.0 que luego se convertiría en estándar internacional en 1997. El W3C propone HTML 3.0 en abril de 1995 pero la IETF no realiza ninguna acción. Los navegadores tomarán luego ideas de estas iniciativas en proceso y las implementarían a su manera para atraer usuarios.

A inicios de 1997 la IETF traslada la responsabilidad de estandarización al W3C, quien publicaría recomendaciones con una eficiencia mayor. Se publica el HTML 3.2 adoptando etiquetas y atributos de marcado visual de Netscape (como b y font). A final del mismo año (1997), el W3C presenta el trabajo de estandarización más notorio hasta la fecha, conocido como HTML 4.0. Un esfuerzo que considera las extensiones derivadas de la guerra de navegadores y las raíces del HTML. En ella, las etiquetas de marcado visual serían desaprobadas {deprecated} en favor de CSS; pero su uso se había difundido tanto que el W3C resolvió por generar tres variantes de HTML 4.0:

Dos años después, a finales de 1999, se le haría una ligera modificación al estándar HTML 4.01, cuya variación estricta (HTML 4.01 Strict) sería adoptado como estándar internacional (ISO/EIC 15445:2000), suplantando la versión 2.0 de 1997. Tras ello, el trabajo de estandarización dejaría de lado al HTML para concentrarse en el XHTML.

En febrero de 1998 el W3C publicó el estándar XML {Extensible Markup Language}. En enero de 2000 se reformuló HTML 4.01 como una aplicación XML en lo que se conoce como XHTML 1.0. Una actualización XHTML 1.1 se emitió como recomendación en mayo de 2001 que permite modularizar el HTML para necesidades específicas. Los módulos más destacables han sido XHTML-Basic que incluye el conjunto mínimo de características que cualquier navegador debe soportar, incluso de dispositivos móviles, y XHTML-MP {mobile profile} con controles aptos para dispositivos móviles. A partir de 2002, el W3C descartaría HTML y se concentraría exclusivamente en formular XHTML 2.0.

Netscape Navigaror e Internet Explorer en la primera guerra de navegadores tuvieron equipos de desarrollo enfocados en agregar funcionalidad no estandarizada tan rápido como fuese posible, con poco control de calidad. Esto llevó a que ambos navegadores no se apegaran a los estándares, fuesen "pulgosos", e inseguros. Pese de hacerlo público, el código fuente de Netscape fue descartado por la Fundación Mozilla. Por su parte, Microsoft tras ganar la guerra mantuvo su navegador en el letargo por varios años.

Un navegador poco mencionado durante la primera guerra fue Opera. Inició en 1994 como un proyecto de investigación de la compañía noruega Telenor. Su primera versión disponible al público fue en 1996 en forma comercial, o gratuita con publicidad, modelo que podría explicar su poca popularidad. A partir de la versión 8.5 de 2005, se distribuye sin costo ni publicidad alguna. Se caracterizó por ser un navegador en apegarse a los estándares, influir activamente en ellos, y en la inclusión de características amigables para el usuario, como es el uso de pestañas (tabs), gestos de dispositivos de apuntar (mouse gestures), velocidad, seguridad y correr en dispositivos móviles.

La Fundación Mozilla adoptó las amenidades descritas para su navegador. Las primeras versiones aparecieron a finales del 2002, con nombres que después serían cambiados por conflictos con productos existentes, hasta quedar Firefox, el cual se liberó en noviembre de 2004. Desde el 2003 Mozilla Firefox empezó lentamente a atraer usuarios de Internet Explorer, en especial por sus problemas de seguridad y la falta de iniciativa de Microsoft por corregirlos.

En el 2003 Microsoft anunció que descontinuaría Internet Explorer for Mac que era el navegador por defecto en este sistema operativo. Apple reaccionó creando un navegador que lo reemplazara. A partir del motor KHTML usado en el navegador Konkeror para Linux, generó WebKit, y lo usó en su navegador Safari que apareció en el mismo año.

Microsoft reaccionó a estos nuevos navegadores hasta octubre de 2006 con Internet Explorer 7 (la versión 6 data de 2001), imitando características de Opera y Firefox. Esto no logró detener la creciente tasa de usuarios que seguían cambiando a Firefox. Por su parte, una semana después, Mozilla liberó Firefox 2.0 con mejoras de usabilidad y seguridad, lo que pondría en evidencia la segunda guerra de navegadores. Esta vez luchando por proveer mejor experiencia de usuario y apego a los estándares.

En el 2008 Google liberó el navegador Chrome basado en WebKit, que sobresalía por su velocidad y era el navegador por defecto en el sistema operativo más usado del mundo: Android. Chrome lentamente comenzó a ganar mercado de Internet Explorer y Firefox hasta convertirse en el navegador más popular a la fecha (ene-2020), con aproximadamente 65% del mercado, seguido por Safari (~17%), y Firefox (~5%), de acuerdo a StatCounter y NetMarketShare. En 2013 Google creó su propia adaptación del motor de "renderizado" WebKit llamada Blink.

Microsoft liberó la versión 8 de Internet Explorer en marzo de 2009 imitando funcionalidades de la competencia e incrementando el apego a los estándares. Microsoft seguió produciendo nuevas versiones aproximadamente cada dos años, hasta el 2015 en que descontinuó Internet Explorer en favor de un nuevo navegador Microsoft Edge construido inicialmente "desde cero" y luego sobre el motor Blink y otras funcionalidades creadas por Google.

La segunda guerra de navegadores se mantiene hasta el presente, donde cada fabricante libera versiones con frecuencia, trata de influir en los estándares (como se verán en el próximo apartado), e implementar la mayor parte de ellos antes de la competencia.

Como se indicó anteriormente, el proceso de estandarización por parte del Consorcio Web (W3C) dejó de lado HTML y se dedicó exclusivamente a XHTML 2.0 entre agosto de 2002 y julio de 2006. Sin embargo, el futuro de la web basado en XHTML 2.0 sólo alcanzó el nivel de notas y no de recomendación. Mientras este trabajo de estandarización ocurría en el W3C, un grupo de interesados consideraron inadecuada la orientación que había tomado el W3C hacia en la especificación formal de documentos con XHTML 2.0. Este grupo de interesados estaba compuesto principalmente por fabricantes de navegadores que seguían las prácticas de Opera (Mozilla Foundation, Opera Software, y Apple), y que se autodenominaron WHATWG (Web Hypertext Application Technology Working Group).

El WHATWG formuló un borrador llamado Web Applications 1.0, que luego fue renombrado a (X)HTML5, y que no rompía la compatibilidad con la web existente, lo cual eximiría a millones de sitios web de tener que migrar al potencial XHTML 2.0. (X)HTML5 extendería a HTML 4 y XHTML 1.1 con nuevos elementos, documentaría formalmente el comportamiento de los navegadores ante código con errores, y tendría una orientación más enfocada al desarrollo de aplicaciones web con JavaScript que en la especificación de documentos con XML. En el 2008 el W3C resolvió por adoptar la propuesta (X)HTML5 del WHATWG como estándar web.

El WHATWG continuó trabajando en (X)HTML5 con la siguiente organización. Cualquier persona del mundo puede participar como "contribuidor" al unirse a la lista de correo y ofrecer sugerencias. Un grupo cerrado de "miembros" escogidos por invitación deciden los cambios en (X)HTML. Una persona escogida como "el editor" refleja los acuerdos en la especificación. El WHATWG decidió no usar números de versiones para identificar los cambios, sino que los cambios que haga el editor en el documento aprobados por los miembros, se consideran oficiales. De esta forma, el WHATWG encontró inapropiado el término (X)HTML5 por contener un número de versión, y lo renombró HTML, el estándar vivo (HTML Living Standard).

Por su parte el W3C continuó usando el término (X)HTML5 y trabajando con versiones. El W3C generó cuatro versiones: (X)HTML 5.0 de 2014 con un borrador del HTML Living Standard de 2007 (2007-2014), (X)HTML 5.1 (2012-2016), y (X)HTML 5.2 (2015-2017). El WHATWG considera estas versiones simplemente como instantáneas (snapshots) del HTML Living Standard. El W3C reconoció que tener dos estándares es trabajo redundante y el desfase es perjudicial para los desarrolladores. Por lo tanto, en mayo de 2019 elevó el HTML Living Standard como oficial y participa en su formulación junto con el WHATWG.

El HTML Living Standard es publicado por el WHATWG en su sitio web. Es un documento de más de 1200 páginas que abarca no sólo el lenguaje (X)HTML. También formaliza el modelo de objetos (DOM, Document Object Model) y otras tecnologías disponibles a través de JavaScript ideadas para facilitar el desarrollo de aplicaciones web.

Un servidor web {web server} o servidor HTTP {HTTP server} es un programa cuya ejecución es persistente, a veces llamado servicio o demonio, en un equipo conectado a Internet, esperando conexiones de clientes usualmente por el puerto 80. Una vez establecida una conexión, el cliente solicita repetitivamente recursos al servidor mediante el protocolo HTTP y éste responde a cada una de ellas siguiendo los lineamientos del mismo protocolo.

El término servidor web refiere al software y no al hardware donde éste corre, dado que el paradigma de computación distribuida permite que tanto un servidor como un cliente puedan ejecutarse en el mismo o diferente hardware. Hay al menos cuatro formas de ofrecer recursos a través de la web, ordenados en forma descendente por control, y ascendente por facilidad y rapidez de uso.

Un navegador web {web browser} o cliente web {web client} es un software que permite obtener, presentar, recorrer, e interaccionar con recursos disponibles en la web. De los componentes de la arquitectura web, es el más conocido por los usuarios ya que interaccionan directamente con él. Un navegador web es una pieza de software compleja, por lo que usualmente está dividida en al menos dos módulos, el motor y la interfaz.

La modularización entre el motor y la interfaz tiene importantes ventajas. El motor de navegación web se distribuye en forma de biblioteca y permite que otras aplicaciones de software puedan reusarlo. De esta forma, clientes de correo, aplicaciones de ayuda, u otro software que lo necesite, puede manipular documentos web. La Tabla 9 muestra los motores de navegación web más populares al año 2020 y ejemplos de navegadores que los usan.

El navegador web es un tipo de agente de usuario. En terminología web, un agente de usuario {user agent} es cualquier software del lado del cliente que consume recursos web, normalmente ideados para humanos. El término "agente de usuario" proviene del escenario más común, en que estos programas reciben los recursos web y los presentan a las personas, como es el caso de los navegadores. Sin embargo, los agentes de usuario no están restringidos a este escenario. Los siguientes son otros ejemplos de agentes usuario y su propósito:

Un servidor web provee recursos en los que puede estar interesado un cliente. Todo recurso transferible entre el servidor y el cliente debe estar identificado de forma única en el mundo mediante un texto (string) llamado identificador uniforme de recurso {URI, Uniform Resource Identifier}. Los URI fueron definidos por Berners-Lee junto con el Grupo de Trabajo de Ingeniería de Internet {IETF, Internet Engineering Task Force} en el RFC 1630 de 1994.

Los URI son extensibles. Berners-Lee y el IETF definieron dos tipos de URI:

La sintaxis de los URN y los URL es compatible, por lo que se pueden considerar la misma notación. En el RFC 3986 de 2005, Berners-Lee y el IETF decidieron descontinuar el uso de los términos URN y URL, a favor de URI. En más de 15 años, esta práctica no ha sido adoptada mundialmente, que continúa empleando el popular término URL.

El RFC 3986 especifica formalmente la sintaxis de un URI usando la notación aumentada de Backus-Naur {ABNF, Augmented Backus-Naur Form}. Por su parte, este material usará la notación informal del Listado 1 con el fin de facilitar su comprensión.

La mayoría de componentes de un URI son opcionales. Su obligatoriedad depende del esquema usado para acceder al recurso. Los componentes de un URI son los siguientes.

La arquitectura web establece que un servidor web provee al mundo recursos identificados de forma única con textos URI. Un agente de usuario interesado solicita estos recursos y el servidor responde con ellos a través de paso de mensajes. Las convenciones usadas en el trasiego de estos recursos entre el cliente y servidor las establece el protocolo de transferencia de hipertexto {HTTP, Hypertext Transfer Protocol}.

Cuando el agente de usuario necesita un recurso, emite un mensaje de solicitud HTTP {HTTP request} al servidor. El servidor web carga el recurso desde el disco, una base de datos, la salida de un programa, u otra otra fuente, y responde con una respuesta HTTP {HTTP response}.

Una sesión HTTP {HTTP session} es una secuencia de solicitudes-respuestas entre el agente de usuario y el servidor web. En la versión HTTP/1.0 de 1996 se establece una sesión por cada transferencia. Es decir, se inicia la sesión, el cliente solicita un recurso, el servidor responde y se cierra la sesión inmediatamente. Para transferir un nuevo recurso se debe iniciar otra sesión HTTP. En la versión HTTP/1.1 de 1999 (RFC 2616) la sesión permite un número arbitrario de transferencias lo que agiliza la comunicación entre ambas partes. A partir de 2014 el protocolo HTTP/1.1 es regido por la familia de RFC de la Tabla 10.

Supóngase que el sitio web ubicado en www.ejemplo.com está en construcción y tiene sólo dos recursos, un index.html y una imagen img/ucr.png. El contenido del recurso index.html se encuentra en el Listado 4.

Un visitante accede con su navegador a www.ejemplo.com. La interacción entre el navegador web y el servidor web se aprecia en el diagrama de secuencia de la Figura 21.

Al escribir la dirección http://www.ejemplo.com/ el navegador contacta a la máquina pasarela {default gateway} que tenga configurado el sistema operativo de la máquina local y le pide que le resuelva la dirección IP del dominio www.ejemplo.com. Al obtener la dirección IP, el navegador establece una conexión TCP en el puerto 80 con www.ejemplo.com y éste acepta. A partir de este momento se ha establecido una sesión HTTP; el navegador y el servidor web pueden intercambiar mensajes HTTP.

El navegador solicita el recurso que el usuario indicó en el URI, en este caso es “/”. Ensambla un mensaje de solicitud {HTTP Request} con el método GET, escribe algunos campos de encabezado (HTTP request header fields) y un cambio de línea. Lo envía al servidor.

El servidor recibe la solicitud HTTP y de acuerdo a su configuración local, obtiene que el recurso “/” equivale al archivo index.html. Ensambla una respuesta HTTP {HTTP response message} con el código de estado 200 {status code} indicando que el recurso fue encontrado y la solicitud se procesó exitosamente. Agrega unos campos de encabezado de respuesta {HTTP response header fields} y anexa el contenido del recurso index.html literalmente en el cuerpo del mensaje. Lo envía al cliente.

El navegador recibe el mensaje de respuesta HTTP y viendo que la solicitud fue exitosa, extrae el recurso index.html guiado por los campos de encabezado HTTP y lo almacena en su caché, probablemente en forma de archivo. El motor del navegador {web rendering engine} inicia el análisis parsing y despliegue {rendering} del recurso en la ventana del usuario. Al analizar la línea 4 del index.html, el navegador descubrirá que necesita otro recurso para presentarlo en la página, y ensambla otra solicitud al servidor, de la misma forma que hizo con index.html, pero esta vez por img/ucr.png.

El servidor web recibe la nueva solicitud y la procesa de la misma forma que hizo previamente con index.html. El recurso también existe. La única diferencia es que img/ucr.png es un recurso binario, de ahí la importancia de los campos del encabezado que ayudarán al navegador a procesar el recurso adecuadamente, en especial el Content-type: image/png. El servidor envía el mensaje de respuesta.

El navegador recibe el mensaje y al ver que es exitoso, agrega el recurso en su caché y guiado por los campos del encabezado del mensaje, interpreta el contenido binario como una imagen PNG y el motor del navegador la coloca en su lugar dentro de la ventana. Aunque podría no hacerlo, el navegador guarda una copia del recurso su memoria caché identificado por su URI, por una razón de eficiencia. Cada vez que el navegador tiene que cargar un recurso (URI), revisa primero su caché. Si tiene una copia, solicitará al servidor información sobre el recurso con el método HEAD, para determinar si el recurso ha cambiado en el servidor. Si no ha cambiado, cargará la copia del caché y evitará consumo de recursos (ancho de banda) y espera de los usuarios.

Al analizar la línea 5 del documento index.html (Listado 4), el navegador encontrará de que necesita también el recurso img/ecci.png. Ensambla una nueva solicitud GET y la envía al servidor como hizo anteriormente. El servidor web recibe la solicitud y trata de localizar el recurso. Al notar que no se encuentra en su sistema de archivos, construye una respuesta HTTP con código de estado 404 Not Found, indicando que el agente del usuario solicitó un recurso que no puede ser resuelto. En el cuerpo del mensaje agrega un texto más explicativo y en los campos del encabezado HTTP detalles de cómo interpretar este texto. Lo envía al cliente.

El navegador recibe el mensaje de respuesta 404 Not Found. Al no obtener un recurso para desplegar {rendering}, opta por dibujar un rectángulo genérico indicando la ausencia y rellena con el texto alternativo que se encuentra en el documento index.html. Continúa de esta forma analizando y desplegando el recurso index.html hasta alcanzar su final.

El alojamiento web {web hosting} es la infraestructura básica requerida para que un sitio web pueda funcionar. Si usted desea publicar un sitio web que esté disponible al menos el 99% del tiempo para sus usuarios, deberá abordar tareas como las siguientes.

Si usted realiza la lista no-exhaustiva anterior, estará haciendo un alojamiento interno {in-house hosting}. Tiene la ventaja de conferir seguridad física y control sobre la infraestructura. Sin embargo, adolece de muchas desventajas que pueden hacerse evidentes ante una gran demanda de usuarios, fallos de hardware, cortes eléctricos, o caídas de conectividad. Muchos equipos web prefieren evitar el alojamiento interno y delegar las responsabilidades a una organización que se especialice en brindar servicios de alojamiento web. El término "alojamiento" u "hospedaje" es una metáfora de las personas que pagan para ocupar un espacio físico y acceder a los recursos de un hotel o apartamento.

La oferta de proveedores de alojamiento web es considerable y variada, desde lo gratuito y limitado hasta lo ostentoso. La elección del proveedor no debe tomarse a la ligera. Un servicio lento o intermitente creará en los visitantes una mala imagen del sitio web sin importar qué tan bien esté programado o diseñado. Si se va a contratar alojamiento web, conviene encontrar un balance entre el costo y el rendimiento. La primera decisión a tomar es el tipo de alojamiento a adquirir, que usualmente se clasifica en las siguientes cuatro categorías.

Para pequeños sitios web documentales o desarrollos incipientes, el autor puede beneficiarse de servicios de alojamiento web gratuitos. Existen aplicaciones web que listan y comparan estos servicios, por ejemplo Free Web Hosting. Antes de decidirse por uno, revise los términos de servicio y otros detalles para saber que cubren sus necesidades y evitar sorpresas.

Disponible en la edición completa de este material.

Normalmente un equipo de desarrollo dispone de tres instancias del sitio web:

Normalmente los ambientes anteriores están en computadoras diferentes. La complejidad puede crecer si los ambientes son distribuidos, por ejemplo, si el almacenamiento está en un servidor dedicado o se usan aplicaciones en sistemas operativos distintos. Es un trabajo arduo dar mantenimiento a esta infraestructura. Existen herramientas de uso difundido que ayudan en esta labor basadas en contenedores (por ejemplo, Docker), o en virtualización (por ejemplo, Vagrant).

Disponible en la edición completa de este material.

La declaración XML indica que el archivo de texto es un documento que sigue las reglas XML e indica la codificación del mismo. Tiene la forma mínima <?xml version="1.0"?> y a modo de ejemplo el Listado 7 presenta su forma más amplia. El prólogo tiene sintaxis de una instrucción de procesamiento, es decir, una etiqueta que se abre y cierra con un signo de pregunta. Tiene tres atributos: la versión, la codificación, y el documento autónomo:

Es sabido que las cartas, tesis, guiones y las guías telefónicas son documentos que tienen una estructura muy diferente. Es decir, poseen elementos distintos, cada uno con su propia distribución y orden. Se dice que son tipos de documentos distintos. En XML cada tipo de documento se define en una notación formal que plasma su estructura llamada definición de tipo de documento {DTD, document type definition} y se estudiará luego. Un documento puede declarar que es de un tipo de documento particular utilizando la declaración de tipo de documento {document type declaration}, como se hizo en la segunda línea del Listado 6, indicando que ese documento es de tipo book:

Se puede pensar en un DTD como una clase en programación orientada a objetos, mientras que un documento XML que sea de ese tipo de DTD es como un objeto que instancia esa clase. El "objeto" documento XML debe cumplir a cabalidad con la estructura descrita en su DTD, cuando esto ocurre, se dice que el documento es de tipo válido o simplemente válido, de lo contrario, se dice que el documento es de tipo no válido o simplemente no válido (o incluso, inválido) (Goldfarb & Prescod, 1999).

Un documento XML puede no tener un tipo de documento definido, es decir, carece o no cumple con un DTD, por lo que es un documento no válido pero puede respetar la sintaxis XML, en tal caso se dice que sólo es un documento bien formado {well formed}. Los documentos bien formados pero no válidos (no cumplen un DTD) suelen utilizarse para documentos pequeños que deben escribirse de forma rápida. Los documentos válidos siempre están bien formados y son necesarios cuando son muy extensos o deben procesarse por algún sistema computacional (Goldfarb & Prescod, 1999).

La declaración DOCTYPE indica el tipo de documento y además instruye al procesador de XML dónde encontrar la definición del tipo de documento (DTD), el cual puede estar escrito en el mismo documento XML o puede encontrarse en una entidad externa (un archivo en disco o red) o una combinación de ambas. Lo más común es que se encuentre en un recurso externo, como se hizo en la segunda línea del Listado 6, la cual instruye al procesador XML que el tipo de documento está en el archivo book.dtd en la misma ubicación que el documento XML. La palabra SYSTEM indica al sistema que busque el recurso especificado en el URI (Universal Resource Identifier) que le continúa. Más adelante se estudiará la nomenclatura de un DTD.

El identificador del elemento que continúa inmediatamente después de <!DOCTYPE, por ejemplo, book en el Listado 6, indica al procesador XML a partir de qué elemento del DTD se debe incluir, es decir, sólo se incluye el subárbol cuya raíz es precisamente ese elemento.

En XML los identificadores se usan para dar nombre a los elementos, entidades u otros. Por ejemplo, la línea 4 del Listado 6 incluye tres identificadores: book, name y version. Los identificadores deben iniciar con una letra y pueden estar seguidos de cero o más letras o los caracteres punto, guión o dígitos. Los identificadores en XML son sensitivos a mayúsculas y minúsculas {case sensitive}, esto implica, por ejemplo que book, Book y boOK se tomen como identificadores distintos. El autor puede emplear cualquier identificador válido, excepto aquellos que inician con la cadena “xml” en cualquiera de sus combinaciones de mayúsculas y minúsculas, ya que están reservados para propósitos de estandarización (Goldfarb & Prescod, 1999).

Los elementos XML {XML element} son las partes que componen un documento. El autor debe indicar entre todo el texto que compone el documento, qué trozo de texto conforma cada parte del documento. Sintácticamente un elemento se forma marcando la parte del documento entre dos etiquetas. Es decir, el texto (datos de carácter) que conforma un elemento se encierra entre un par de etiquetas. Una etiqueta {tag} es el texto entre un par de signos "menor que" y "mayor que". Sintácticamente, un elemento es la combinación de una etiqueta de inicio (que puede tener atributos), un contenido opcional, y una etiqueta de cierre, como muestra el Listado 8:

Un elemento tiene dos etiquetas, una de inicio y otra de cierre (o etiqueta de fin). La etiqueta de inicio XML {XML start-tag} se compone de un carácter menor que (<), un id_etiqueta_inicio que es un simple identificador y debe respetar las restricciones de los identificadores, seguido por cero o más parejas atributo="valor", y un carácter de mayor que (>).

La etiqueta de cierre XML o etiqueta de fin XML {XML end-tag} consta de los caracteres menor que (<) y un slash (/), luego un id_etiqueta_cierre que obligatoriamente debe ser el mismo identificador que el de la etiqueta de inicio del elemento y un carácter de mayor que (>). La etiqueta de cierre nunca tiene atributos.

El contenido del elemento XML {XML element content} puede ser vacío o texto XML, es decir, datos de carácter, otros elementos (y por ende etiquetas) o ambos. Si un elemento no tiene contenido se dice que es un elemento vacío, y se puede escribir en cualquiera de las dos formas del Listado 9.

La segunda de las formas del Listado 9 consta de una sola etiqueta llamada etiqueta vacía XML {XML empty-element tag}, la cual finaliza en un slash (/) indicando que el elemento ha terminado. Es poco común encontrar etiquetas vacías sin atributos.

Un elemento vacío no puede tener ninguna forma de contenido, ni siquiera espacios en blanco o cambios de línea. Es decir, que si en la primera forma del Listado 9 se incluyera un cambio de línea, se consideraría como un dato de carácter y ese sería el contenido del elemento. Por el contrario, si un elemento tiene contenido (no es vacío) y se omite alguna de las etiquetas (la de inicio o la de fin) el procesador XML deberá alertar de que el documento no está bien formado.

Debe quedar claro que las etiquetas no son elementos. Las etiquetas inician con un < y terminan con un >, lo demás no son etiquetas (Goldfarb & Prescod, 1999). Los elementos tienen etiquetas y contenido. Los elementos se escriben en el documento XML y son instancias de los tipos de elementos, los cuales se declaran en la definición del tipo de documento (DTD).

Los elementos pueden tener atributos que son "una forma de incorporar características o propiedades a los elementos de un documento" (Goldfarb & Prescod, 1999, p. 353). Los atributos se escriben siempre en la etiqueta de inicio (Listado 10). Un atributo se compone de un identificador, un signo de igual (=) y un valor entre comillas dobles, simples, o una combinación de ambas siempre y cuando la comilla que cierra sea del mismo tipo de la que abre.

Cuando se crea un nuevo tipo de documento, es difícil decidir qué representar con elementos y qué con atributos. Las siguientes diferencias pueden ayudar en la decisión. Más adelante se retomarán estas diferencias a un nivel más formal.

Cuando se escribe un documento XML el autor escoge los identificadores de los elementos, los atributos, y la estructura a su gusto, y la plasma en un DTD. Cuando una persona observa el marcado de un documento XML y se pregunta "¿qué significa esto?" o bien "¿qué aspecto tendrá después?", estará haciendo preguntas sobre su semántica. Por ejemplo, si se encuentra una etiqueta <T> esta podría indicar que se trata de un título, una tabla, o alguna otra cosa (Goldfarb & Prescod, 1999).

La computadora no puede inferir la semántica de un documento XML dado, sino que es responsabilidad del autor de la gramática describir esta semántica para que otros autores puedan comprenderlo. Esta descripción se puede realizar en un documento PDF (Portable Document Format), un libro, o cualquier otro medio de comunicación (Goldfarb & Prescod, 1999). Más adelante se hará en comentarios en el DTD.

Como señalan Goldfarb y Prescod, "lo que le interesa a la computadora es el aspecto que se supone debe tener un elemento cuando está formateado, la forma en que debe actuar si es interactivo o qué hacer después de extraer los datos. Estas cuestiones se encargan de especificarlas las hojas de estilo y los programas informáticos" (Goldfarb & Prescod, 1999, p. 350).

Una entidad XML {XML entity} es similar a una constante de un lenguaje de programación. Una constante tiene un nombre y un valor. Cada vez que se escribe el nombre de la constante, el compilador lo reemplaza por su valor. Una entidad XML es como una constante cuyo valor es cualquier trozo de texto: un carácter, un párrafo, un archivo (incluso binario), o todo un libro. A las entidades se les da nombre, y su valor se puede obtener mediante una referencia de entidad XML {XML entity reference}, con la notación &entidad;. Por ejemplo, < en un documento XML es reemplazado por el símbolo “<”. Aunque XML define muchos tipos de entidades, en este documento sólo se estudiarán las entidades predefinidas.

Las entidades predefinidas XML {predefined XML entities} "son marcas que representan caracteres que de otro modo se interpretarían con un significado especial" (Goldfarb & Prescod, 1999, p. 358), como los caracteres menor que (<) y ampersand (&). Existen cinco entidades predefinidas mostradas en la Tabla 15. "Cuando el procesador XML analiza el documento, reemplaza las referencias de entidad por los caracteres reales", en lugar de interpretarlos como caracteres de marcado (Goldfarb & Prescod, 1999, p. 359).

Nótese que las etiquetas se delimitan con paréntesis angulares (< y >), y las referencias a entidades entre el signo & y el punto y coma (;). Se dice que el texto encerrado dentro de estos cuatro caracteres se conoce como marcado XML {XML markup}, lo restante como datos de carácter XML {CDATA, XML character data}. La combinación del marcado más los datos de carácter forman el texto XML {XML text} (Goldfarb & Prescod, 1999).

Aunque el uso de entidades predefinidas parece sencillo, hace que el documento XML se vuelva difícil de leer y editar para el autor. Este fenómeno es evidente cuando las entidades se usan repetidamente, por ejemplo al escribir segmentos de código fuente. Por este motivo se crearon las secciones CDATA. Una sección CDATA {XML CDATA section} indica al procesador XML que no interprete una parte del texto aunque contenga marcado, es decir, que lo trate como datos de carácter {CDATA, character data}. La sintaxis de una sección de datos de carácter se aprecia en el Listado 11.

En el contenido puede aparecer cualquier cadena de texto, excepto la que cierra la sección CDATA (]]>) llamada CDEnd (contracción de character data end). La línea 29 del Listado 6 usa dos entidades preestablecidas. Este mismo elemento puede escribirse con una sección CDATA. El Listado 12 muestra el elemento escrito de ambas formas.

Los comentarios son cadenas de caracteres que no son parte de los datos de carácter, es decir, es parte del marcado pero que debe ser ignorado por el procesador XML. Permiten al autor hacer anotaciones que le ayuden a comprender o recordar partes del documento. El texto del comentario se introduce entre los caracteres inicio de comentario (<!--) y final de comentario (-->), como el Listado 13.

Todo el texto dentro del inicio y fin de comentario será ignorado, incluyendo los caracteres de marcado (menor que, mayor que, ampersand, y punto-y-coma), excepto la secuencia de cierre del comentario (-->). Para algunos procesadores XML la secuencia de dos giones (--) es prohibida dentro de un comentario. Aunque no es obligatorio, se recomienda separar los dos guiones (--) del texto de los comentarios por un espacio en blanco, como se hizo anteriormente y no como el Listado 14:

Es natural querer combinar diferentes tipos de documentos. Por ejemplo, en una presentación incluir una fórmula o un gráfico, o en un documento incluir una hoja de cálculo (como una tabla). Si un documento XML se incrusta dentro de otro, y ambos utilizan un mismo identificador con propósitos distintos, habrá una colisión de nombres. Por ejemplo, el documento web del Listado 16 tiene una figura SVG incrustada entre las líneas 8 a 15. Ocurre una colisión con los elementos <a>: el de la línea 9 pertenece a la imagen SVG y el de la línea 17 pertenece a XHTML.

Para evitar colisiones se utilizan espacios de nombres (namespaces). Los espacios de nombres permiten distinguir los elementos que pertenecen a un tipo de documento de los que pertenecen a otro tipo de documento, llamados también vocabularios. Los espacios de nombres distinguen los elementos de diferentes vocabularios (tipos de documentos) agregando un prefijo a los identificadores de los elementos, de la forma Prefijo:NombreElemento. El Listado 17 distingue el vocabulario al que pertenecen todos los elementos del documento.

En el Listado 17 se dice explícitamente a qué vocabulario o espacio de nombres pertenece cada elemento del documento. Se usó el prefijo h para identificar a los elementos que pertenencen a XHTML y el prefijo s para aquellos que pertenecen a SVG. Estos prefijos se definen con el atributo xmlns, que es una contracción de xml namespace. Recuerde que los atributos que inician con xml están reservados por el estándar.

Todos los elementos XML tienen un atributo xmlns implícito. Cuando el autor lo hace explícito, define un espacio de nombres de la forma: xmlns:Prefijo="URI". El Prefijo es sólo un identificador de uso interno en el documento. El elemento donde aparece el atributo xmlns y todos sus hijos pueden utilizar el Prefijo para hacer explícito el espacio de nombres al que pertenencen. Es decir, el elemento y sus hijos pueden utilizar la notación Prefijo:Elemento en sus etiquetas de inicio y de cierre. Se usa un URI para identificar al espacio de nombres de forma única. El URI no es necesario que exista, pues el procesador XML no lo consulta. Sólo se debe usar consistentemente para identificar al espacio de nombres y evitar que colisione con espacios de nombres definidos por otros usuarios.

Se pueden definir tantos prefijos como vocabularios se usen en el documento. En el Listado 17 se definieron dos prefijos: h y s, ambos en el elemento raíz html de la línea 4. El atributo xmlns puede repetirse en un mismo elemento porque el prefijo se considera parte del nombre del atributo. El prefijo también forma parte del nombre de los elementos que lo utilicen. Con el uso de ambos espacios de nombres en el Listado 17, es claro para un software XML distinguir que el elemento a de la línea 9 es un enlace SVG, y que el elemento a de la línea 17 es un enlace XHTML.

Si al definir un espacio de nombres con el atributo xmlns se omite el prefijo, se estará indicando el espacio de nombres global. Todos los elementos hijos que no expliciten un prefijo pertenecen al espacio global. En la línea 4 del Listado 18 se indica que el espacio de nombres global es XHTML, a excepción de los elementos que inician con el prefijo s, pues son elementos SVG. El espacio de nombres s se definió en el elemento svg de la línea 8, pero es más usual hacerlo en el elemento raíz como es el caso de xhtml en la línea 4. Este ejemplo muestra otro detalle. Los enlaces a de SVG usan el estándar XLink, el cual requiere su propio espacio de nombres (línea 9).

En el DTD se escriben las declaraciones de tipo de elemento XML {XML element type declarations} que son restricciones que deben respetar todos los elementos en un documento XML válido. Estas declaraciones tienen la sintaxis del Listado 20.

El <!ELEMENT inicia la declaración de un tipo de elemento. El IdElemento es el identificador que aparece en sus etiquetas. Debe ser único en el DTD y respetar las restricciones de los identificadores XML. La EspecContenido se refiere a la especificación de contenido, que indica qué objetos pueden figurar en el contenido del elemento, hay cuatro posibilidades listadas en la Tabla 16 (Goldfarb & Prescod, 1999):

Cuando un elemento tiene subelementos (o elementos hijos) en el contenido (últimos dos casos de la lista anterior), es necesario especificar un modelo de contenido XML {XML content model}, que establece el orden y número de apariciones de los subelementos. El orden de los elementos hijos se establece con los caracteres coma (,), barra vertical (|) y paréntesis redondos. Una secuencia de subelementos separados por coma indica que tales subelementos deben aparecer y en el mismo orden. La barra vertical indica que debe aparecer sólo uno de los dos subelementos que están en sus extremos. Los paréntesis agrupan partículas de contenido que son tratadas como unidades por los operadores anteriores, lo que permite combinarlos.

El número de apariciones de los subelementos se especifica con los indicadores de frecuencia que se escriben al final del subelemento y sin espacios en blanco. Existen tres indicadores de frecuencia. El signo de interrogación (?) indica que el elemento hijo es opcional, es decir, puede o no puede aparecer. El asterisco (*) indica que el subelemento puede aparecer 0 ó más veces (opcional y repetible). El signo de más (+) indica que el subelemento debe aparecer 1 o más veces (necesario y repetible) (Goldfarb & Prescod, 1999).

Los atributos "son una forma de incorporar características o propiedades a los elementos de un documento" (Goldfarb & Prescod, 1999, p. 353). Un elemento puede tener una lista de atributos, la cual se declara en el DTD en la sección conocida como declaración de lista de atributos, usualmente después de la declaración del tipo de elemento. Tiene la sintaxis del Listado 21.

El <!ATTLIST indica que se va a declarar la lista de atributos del elemento identificado por IdElement. Los atributos continúan uno tras otro separados por espacios en blanco, sin impotar si son cambios de línea o no. Cada declaración de atributo se compone de un identificador (IdAttN), el tipo de datos (AttTypeN), y el valor por defecto (DefaultValueN). IdAttN indica el nombre del atributo, debe ser un identificador válido y no es obligatorio que sea único en el documento. El tipo del atributo AttTypeN puede ser alguno de los listados en la Tabla 17.

El DefaultValueN en la declaración de la lista de atributos del Listado 21 indica si el atributo se puede omitir o no, y el valor por defecto en caso de que se omita. Puede tomar las tres variantes listadas en la Tabla 18.

No es trivial decidir qué aspectos del mundo real modelar como elementos y cuáles como atributos. El autor ha de escoger alguna convención que sea coherente y escribir un DTD para obligar a todos los documentos del mismo tipo a cumplir con el diseño escogido. Aunque no hay ninguna regla para decidir qué debe modelarse como un elemento o un atributo, Goldfarb y Prescod sugieren las siguientes ideas.

Los atributos no pueden contener "subatributos" ni elementos, sino que son pequeños trozos de texto sin estructura o listas de condiciones. Por tanto, si algo del mundo real contiene otras partes que también necesitan modelarse, debe hacerse con elementos y no con atributos. Los atributos se usan para añadir poca información, sencilla y sin estructura (Goldfarb & Prescod, 1999).

Los elementos deben respetar el orden y el número de ocurrencias descritos en el DTD, mientras que los atributos pueden aparecer en cualquier orden y no pueden repetirse. Por esto, las "cosas" que deben repetirse o que respetan cierto orden deben modelarse como elementos y no como atributos (Goldfarb & Prescod, 1999).

Si las ideas anteriores no son criterio suficiente, puede usarse la siguiente heurística. Los elementos se utilizan para representar partes de los objetos, o datos que son parte del contenido principal, y deben aparecer en las impresiones o interpretaciones del documento. Los atributos se utilizan para representar propiedades de los objetos, es decir, información sobre los datos reales (metadatos) y que no necesariamente se imprime (Goldfarb & Prescod, 1999).

En la Sección 3.2.3 se indicó que los creadores de un tipo de documento tienen en su mente la semántica de los elementos y atributos. Cuando otras personas leen o necesitan escribir un documento del mismo tipo en XML, enfrentarán dificultades si desconocen esta semántica. Por ejemplo, un elemento <T> podría significar un texto, una tupla, una tabla, un título, u otro concepto. XML es un conjunto de reglas estándar para marcar documentos, pero no ofrece funcionalidad para describir la semántica de los elementos y sus atributos. Los autores elaboran manuales en páginas web, PDF, u otros formatos. Una práctica común y no excluyente, es plasmar la semántica como comentarios en el tipo de documento.

Documentar un tipo de documento consiste en incluir comentarios, usualmente detallados y extensos, con la semántica que otros autores necesitarán para poder comprender, y escribir documentos válidos de ese tipo. Un extracto de un DTD documentado se aprecia en el Listado 22. Un primer comentario contextualiza el tipo de documento, su propósito, los autores, versiones o revisiones, u otra información general. Luego se provee un comentario para cada elemento, el cual describe el elemento, provee un ejemplo, documenta cada atributo, y puede dar sugerencias sobre el contenido esperado.

Disponible en la edición completa de este material.

La declaración del tipo de documento, expresada con la etiqueta <!DOCTYPE …​>, informa al navegador el tipo de documento (HTML o XHTML) y la versión usada en el resto del documento. Con esta declaración el navegador sabrá cómo interpretar la sintaxis y contra cual especificación validar su código. La tabla Tabla 25 muestra tipos de documentos y versiones en uso. Para una lista completa que incluye tipos de documentos para XHTML-Basic y XHTML Mobile Profile, puede consultarse la entrada de tipos de documento en la Wikipedia.

Aunque en HTML es opcional, siempre es conveniente declarar el tipo de documento. Es difícil memorizarlos, por lo que el WHATWG decidió simplificar la declaración para (X)HTML5 a <!DOCTYPE html>, que es la versión recomendada para nuevos documentos (véase Listado 26 y Listado 27).

Si se omite la declaración del tipo de documento la mayoría de navegadores entran en quirks mode, un modo de compatibilidad para poder desplegar páginas web obsoletas que contienen errores {quirks}, con resultados que eran dependientes del navegador. Si la declaración del tipo de documento está presente, el navegador entra en modo estándar {standard browser mode}, y si el documento es válido, el comportamiento debería ser homogéneo entre navegadores.

Existen varias herramientas gratuitas de aseguramiento de la calidad {QA, Quality Assurance} que permiten someter un documento web a un conjunto de pruebas y obtener retroalimentación de si está bien formado, se conforma al tipo de documento que declara, no tiene enlaces rotos, sus estilos son válidos y otras pruebas. Algunos ejemplos de estas herramientas son los siguientes.

Existen otros validadores disponibles no mencionados en la lista anterior. Un código que resulte ser válido tras someterse a varios validadores, se considerará de mejor calidad y con más garantía de funcionar apropiadamente entre navegadores.

Cuando escriba un documento HTML, almacénelo con extensión .html y los documentos XHTML con extensión .xhtml. Aunque la extensión no debería ser algo de importancia, de forma lamentable, parte software web se guía por este detalle en lugar de la declaración del tipo de documento (incluso los validadores del W3C). Si aloja los documentos en un servidor web, es probable que además deba configurarlo para que sirva los archivos XHTML con el MIME {Multipurpose Internet Mail Extensions} application/xhtml+xml. Aunque ya es de poco uso, Internet Explorer 8 y anteriores no despliegan páginas XHTML sino que las ofrecen al usuario para que las guarde en disco.

(X)HTML5 pretende simplificar la web de un modo pragmático. Aunque aquí se incluye el "5" en "(X)HTML5" para diferenciarlo de sus predecesores, sus autores lo llaman realmente "HTML, el estándar vivo", sin ningún número de versión, y por eso no se especifica en el DOCTYPE, ni tampoco su DTD como se aprecia en la línea 1 del Listado 26 y del Listado 27, lo cual hace que deje de ser una aplicación XML válida. Por esto se dice que XHTML5 no existe como un estándar XML. El estándar es HTML5, el cual permite utilizar tanto la notación de HTML como XML, pero sin mezclarlas. Por esto XHTML5 no es una aplicación XML como sí lo es XHTML 1.0. XHTML5 simplemente es un término para referirse al HTML5 que utiliza notación XML.

Dado que XHTML5 no es una aplicación XML, los navegadores ignorarán la declaración XML (<?xml …​?>) en la primera línea del documento, por lo cual es común omitirla, como se hizo en el Listado 26. La declaración de codificación debe hacerse entonces en el encabezado con un elemento meta (línea 4) mucho más sencilla que en XHTML 1.0 (compárese con la línea 7 del Listado 28).

El elemento documento o elemento raíz de un documento (X)HTML es <html>. Aunque no es obligatorio, se recomienda siempre especificar el idioma del documento con el atributo lang (Listado 26 y Listado 27). En XHTML el atributo xmlns es necesario para indicar que sus identificadores pertenecen al espacio de nombres de XHTML (línea 2 del Listado 26) y así evitar que colisionen con otras especificaciones. Especificar el espacio de nombres es la principal diferencia que permite al navegador distinguir si un documento web es HTML5 o XHTML5, además de la extensión del archivo y los códigos MIME. Los demás atributos del elemento <html> son los comunes para casi todos los elementos, llamados atributos globales (X)HTML {(X)HTML global attributes}. El estándar (X)HTML define más de 20 atributos globales. Unos pocos se listan en la Tabla 26.

En XHTML el elemento raíz <html> sólo admite dos elementos hijos: un encabezado (<head>) y el cuerpo del documento (<body>). En HTML estos elementos hijos son opcionales, pero se recomienda incluirlos. Si se omiten, el navegador debe distribuir los elementos al encabezado o al cuerpo de acuerdo a donde irían normalmente, lo cual requiere más procesamiento y por tanto tiempo de carga del documento.

El encabezado del documento (X)HTML {(X)HTML document header} contiene información sobre el documento mismo pero que no es considerado parte del contenido, a lo que frecuentemente se le llama metadatos y son útiles para los navegadores o motores de búsqueda. Los elementos que pueden aparecer en el encabezado son: el título del documento, metadatos, la base del documento, hojas de estilo, y programas de JavaScript. En esta sección se estudiarán los dos primeros.

El título del documento (X)HTML {(X)HTML document title} se escribe como un texto simple en el contenido del elemento <title> y es obligatorio en XHTML. No es parte del contenido del documento porque las personas lo usarán antes de tener acceso a él. Por eso, es uno de los textos más importantes y siempre debe escogerse con cuidado, tratando de que sea corto (menos de 60 caracteres (Connolly & Hoar, 2018)) y descriptivo. Aparece en la barra de título del navegador, y en los resultados de los motores de búsqueda como Google y Bing. Los lectores lo verán en el historial de su navegador y con suerte en sus favoritos.

Los metadatos {metadata} son detalles sobre el contenido del documento como el autor, palabras clave, codificación del texto, y otros que no se pueden especificar con los elementos <title> y <base> (WHATWG, 2020). Se escriben en forma de parejas atributo-valor con el elemento vacío <meta> como el Listado 30. El nombre del metadato se escribe en el atributo name y el valor del metadato en el atributo content. Si el nombre del atributo es el mismo que una de las directivas del encabezado HTTP (Sección 2.2.4.3) se puede escribir en el atributo http-equiv en lugar de name, como la línea 2 en el Listado 30. Cuando un documento web es solicitado, el servidor web puede revisar el encabezado por estos metadatos http-equiv y agregar las respectivas directivas en el encabezado del mensaje de respuesta HTTP {HTTP Response header} que precede al documento.

La recomendación (X)HTML no define un conjunto de valores válidos para ninguno de los atributos de <meta>, sino que permite libremente construir perfiles de metadatos {metadata profiles}. El Listado 30 muestra un ejemplo de encabezado con título y metadatos comunes en XHTML 1.0. Para más detalles, revísese la especificación HTML 4.01. En versiones más recientes de (X)HTML, el W3C ha adoptado una notación más elaborada para la especificación de metadatos llamada Marco de descripción de recursos {RDF, Resource Description Framework}.

El metadato para declarar la codificación del documento (en la línea 2 del Listado 30) es tan común que en (X)HTML5 se agregó el atributo charset (que conceptualmente debió llamarse encoding) al elemento <meta>. De esta forma, los documentos (X)HTML5 pueden especificar la codificación de la forma compacta <meta charset="utf-8"/>, como se hizo en la línea 4 del Listado 26.

Uno de los metadatos más importantes es adaptar la región de visualización de la pantalla {viewport} al dispositivo, como la línea 3 del Listado 30. En general, cuando los navegadores de dispositivos móviles inteligentes cargan una página web, lo hacen para una ventana de un navegador de escritorio, y luego escalan el resultado a las dimensiones de la pantalla del dispositivo. Esta decisión se hace por el hecho de que si se usan las dimensiones del dispositivo, la mayoría de sitios web se verán mal. En consecuencia, el usuario normalmente debe desplazarse {scroll} hacia la información que le interesa dentro de la página y realizar un acercamiento {zoom in} para poder leerla.

La buena práctica del diseño web adaptable {responsive web design} establece que el dispositivo no debe adaptarse al sitio web, sino que el sitio web debe adaptarse al dispositivo del usuario. Para ayudar en esta práctica, Apple Inc. introdujo el perfil de metadatos viewport para su navegador Safari que eventualmente fue implementado en la mayoría de navegadores modernos. El viewport corresponde al área donde se dibujará la página web. El viewport no tiene un único valor, sino varias parejas atributo=valor. El atributo width=device-width indica al navegador que el ancho que tendrá la página web será el mismo que el ancho de la pantalla del dispositivo (línea 3 del Listado 30). El atributo initial-scale=1 indica al navegador que no escale la página inicialmente, es decir, que no realice el zoom out del comportamiento por defecto.

Después del encabezado (elemento <head>) continúa el cuerpo del documento (elemento <body>). El cuerpo del documento almacena el contenido del documento. Esto es lo que ve o escucha el usuario una vez que se ha cargado. El elemento <body> tiene cerca de 16 atributos que son manejadores de eventos y se estudiarán en la parte de comportamiento de este material. El contenido del elemento <body> puede ser texto puro en HTML, pero normalmente es una mezcla de los elementos que se explican en el resto de secciones de este capítulo.

(X)HTML5 define seis elementos para poder dividir o seccionar el contenido de un documento: <header>, <footer>, <nav>, <aside>, <main>, <article> y <section>. El Listado 31 muestra un ejemplo de cómo estos elementos pueden usarse para seccionar el contenido de una página.

El elemento <header> sirve para describir el encabezado de página, de un artículo o una sección. En cuanto a un sitio web, el encabezado puede contener el logotipo o imagotipo de la organización o del sitio, el título del sitio, algún lema, un campo de texto para hacer búsquedas en el sitio web, un control de cuenta de usuario, entre otros elementos. En las líneas 9 a 13 del Listado 32 se muestra un encabezado de sitio web. El atributo id en los elementos (X)HTML es opcional, pero facilita enormemente la labor de presentación (hojas de estilo) y de comportamiento (JavaScript).

El elemento <footer> delimita un pie de página. Sirve para indicar información acerca del sitio web o de una sección, como el autor, enlaces hacia documentos relacionados (como términos de servicio), derechos de autor, un menú de navegación secundario, entre otros. Las líneas 62 a 64 del Listado 32 presentan un pie de página, cuyo texto se escribió dentro de un elemento <small>, redefinido en (X)HTML5 para marcar textos con restricciones legales y similares.

El elemento <nav> sirve para indicar un conjunto de enlaces que proveen navegación de la página misma (como una tabla de contenidos), o del sitio web mismo, como se hizo en las líneas 15 a 24 del Listado 32. Enlaces de publicidad, referencias bibliográficas, resultados de búsquedas, y similares, no deben encerrarse dentro de un elemento <nav>, dado a que no representan navegación dentro del sitio. El elemento <nav> puede contener títulos, listas no ordenadas, párrafos y otros elementos.

El contenido propio de la página web inicia con cualquier elemento que no sea uno de los anteriores. Es apremiante que el autor estructure el contenido utilizando elementos <main>, <article> y <section>.

El elemento <main> marca el contenido propio o dominante del documento, o la funcionalidad principal de una aplicación web, como se hizo en las líneas 26 y 60 del Listado 32. Es decir, el contenido que es único en esta página y no está presente en otras páginas del sitio web. Su principal función es ayudar a las tecnologías de apoyo {assistive technology}, como lectores de pantalla, a saltar directamente al contenido principal de la página. Debe cumplir algunas restricciones. El elemento <main> debe ser único en el documento. Es decir, un documento no debe contener dos elementos <main> a menos de que su visibilidad sea excluyente con el atributo hidden. El elemento <main> debe ser hijo del elemento <body>, aunque con algunas restricciones podría estar dentro de un formulario web (<form>).

De acuerdo a la especificación oficial, el elemento <article> se utiliza para especificar una obra auto-contenida en un documento, página, aplicación o sitio, que se puede distribuir o reutilizar (WHATWG, 2020). Esto implica que un artículo es un trozo de información que puede ser movido de un lugar a otro dentro de la misma página web (a un margen, por ejemplo) y mantener su sentido. Son ejemplos: una entrada de un blog o foro, una noticia, un comentario de usuario, entre otros. Los elementos <article> se pueden anidar. En el Listado 32 se indicó que el contenido principal de la página está compuesto de dos artículos. El primero son las secciones del sitio web (líneas 27 a 53). El segundo es una liberación de responsabilidad en la página pricipal del sitio (líneas 55 a 59).

Los artículos se dividen en secciones temáticas. Por ejemplo, un libro se divide en partes, capítulos y secciones. Cada una de estas partes se identifica con un título. El elemento <section> permite dividir un artículo en partes o secciones, las cuales no son independientes, sino que tienen un orden. Como es de esperar, si una sección de contenido se mueve de lugar dentro de la misma página web (a un margen, por ejemplo), perderá su sentido. En el Listado 32 cada entrada introductoria hacia una parte del sitio web, fue representada como una sección (líneas 34 a 40, y líneas 42 a 49). Las secciones se pueden anidar entre sí. La especificación (X)HTML5 también permite anidar artículos dentro de secciones. Las secciones también pueden tener encabezados, elementos de navegación, y pie de sección.

El elemento <aside> sirve para indicar contenido que no es considerado parte del contenido principal del documento, por ejemplo, publicidad, noticias, artículos relacionados, etc. Si se quiere, el menú de navegación del sitio (<nav>) puede escribirse dentro de un elemento <aside>, para indicar que no es parte del contenido principal.