Taller: diseñar el layout y el look and feel de la aplicación

1. Objetivos de aprendizaje

Al terminar este taller tu equipo va a ser capaz de:

Diseñar un solo layout para la aplicación del grupo: las regiones fijas, el lugar donde se muestran las vistas y los <router-outlet> que lo permiten.
Decidir qué lleva el menú principal a partir de los objetivos de la aplicación y de sus usuarios, y cuál es la vista por defecto.
Acordar un look and feel común: paleta, tipografía, componentes y estados.
Construir un prototipo nuevo en HTML con Bootstrap que muestre ese diseño, y publicarlo junto con las decisiones en la wiki.

Hasta ahora cada integrante construyó su módulo por separado, y en este momento los componentes de todos están “pegados” uno debajo de otro en app.html: la aplicación no tiene menú, no tiene una portada y no tiene una forma común de verse. El Release 8 lo cambia: el Router le da a cada vista su propia URL, y alguien tiene que decidir cómo se ve y cómo se recorre la aplicación completa. Eso es este taller. No escribe Angular: produce el diseño que el Release 8 construye después.

Antes de empezar, ten a mano:

El prototipo que hiciste en la semana 1 y el de tus compañeros.
La teoría de Bootstrap, en especial la grilla.
La teoría de Enrutamiento y Angular Router, porque el paso 2 decide dónde se muestran las vistas.

2. Paso 1: revisar los prototipos de la semana 1

Cada integrante muestra el prototipo que hizo al comienzo de la semana 1 y el equipo lo recorre con cuatro preguntas: qué regiones tiene la pantalla (cabecera, menú, contenido, pie), cómo se pasa de una vista a otra, qué se repite en todas las vistas y qué cambia entre ellas. Anoten qué se conserva y qué se descarta: lo que sirvió en el prototipo de uno puede servir a todos, y lo que solo funcionaba en un módulo no se lleva a la aplicación.

Con eso se arma el inventario de vistas: por cada módulo, las vistas que ya existen (lista, detalle, crear) y las que el Release 7 y el Release 8 agregan (asociar una entidad con otra).

3. Paso 2: el layout y los `<router-outlet>`

El layout es la parte de la pantalla que no cambia cuando el usuario navega, y el lugar donde sí cambia el contenido. Con el Router, app.html deja de ser una lista de componentes y pasa a ser ese esqueleto: el menú, el pie y un <router-outlet />, que es el hueco donde Angular pinta la vista de la ruta activa.

Decidan en equipo:

Las regiones fijas. Una cabecera con el menú arriba, o un menú lateral, o las dos cosas. Qué va en el pie, si va algo.
Dónde se muestra el contenido. Casi siempre es una sola región, con un <router-outlet />. Si algún sitio de la aplicación necesita dos regiones que cambian por separado (por ejemplo, un panel lateral de ayuda que se abre sin tocar la vista principal), cada región lleva su propio <router-outlet>.
Cómo se reacomoda en una pantalla pequeña. Qué columnas se apilan y qué parte del menú se esconde.

Escriban en la wiki el app.html que resulta, con el o los <router-outlet> en su lugar. Este es un ejemplo con un menú arriba, el contenido en una sola región y un pie:

<nav class="navbar navbar-expand navbar-dark bg-dark px-3">
  <a class="navbar-brand" routerLink="/">Música</a>
  <!-- aquí van los enlaces del menú (paso 3) -->
</nav>

<main class="container my-4">
  <div class="row">
    <div class="col-12 col-md-8 offset-md-2">
      <router-outlet />
    </div>
  </div>
</main>

<footer class="text-center text-muted py-3 border-top">
  ISIS2211
</footer>

La grilla de Bootstrap hace el trabajo de la pantalla pequeña: col-12 ocupa todo el ancho en un teléfono, y col-md-8 offset-md-2 lo reduce y lo centra desde el tamaño mediano en adelante. Si dudan de cómo repartir las columnas, la teoría de la grilla lo explica.

4. Paso 3: el menú principal, la vista por defecto y las rutas

El menú no es una lista de módulos. Es la lista de lo que el usuario necesita hacer. Antes de escribir un solo enlace, respondan:

¿Quién usa la aplicación? Si hay más de un tipo de usuario (por ejemplo, alguien que consulta y alguien que administra), no tienen las mismas necesidades ni deberían ver el mismo menú.
¿Cuáles son los objetivos de la aplicación? Qué quiere lograr cada tipo de usuario cuando entra.

Con esas respuestas decidan qué va en el menú principal: pocos ítems, nombrados por lo que el usuario quiere hacer y no por el nombre del módulo del equipo. Un módulo que el usuario casi nunca necesita puede quedar fuera del menú y alcanzarse desde otra vista. Decidan también si el menú es global (uno solo, en app.html) o si cada módulo trae el suyo.

Decidan después cuál es la vista por defecto: la que el usuario ve al entrar a /, antes de elegir nada. Es la vista que mejor responde al objetivo principal de la aplicación, y es la que va en la redirección de la ruta raíz.

Todo eso se registra en una tabla de rutas que es compartida por el equipo:

Ruta	Componente	Módulo	Responsable	¿En el menú?
`/`	Redirección a `/artistas`	Aplicación	Ana	No
`/artistas`	`ArtistList`	Artistas	Ana	Sí, “Artistas”
`/artistas/:id`	`ArtistDetail`	Artistas	Ana	No (se llega desde la lista)
`/artistas/:id/add-album`	`ArtistAddAlbum`	Artistas	Ana	No (se llega desde el detalle)
`/albumes`	`AlbumList`	Álbumes	Luis	Sí, “Álbumes”
`**`	`NotFound`	Aplicación	Luis	No

Las filas de ejemplo son las de los tutoriales (Ana y Luis son nombres de ejemplo); las del equipo salen del inventario del paso 1. Una fila por cada vista, incluidas las de asociación y la ruta de respaldo que atrapa las URL que no existen. El responsable evita que una vista se quede sin escribir porque cada uno cree que le toca al otro.

5. Paso 4: el look and feel

Un look and feel común no es adornar: es que la aplicación se sienta una sola. El equipo acuerda por escrito:

Decisión	Qué se acuerda
Paleta	Un color principal, uno secundario y los de aviso (éxito, error). Cada uno con su nombre y su valor hexadecimal.
Tipografía	Una familia para los títulos y una para el texto, y los tamaños de los títulos.
Componentes	Qué componente de Bootstrap se usa para cada cosa: el botón principal y el secundario, las tablas, los formularios, los mensajes de error. Si dos integrantes usan botones distintos, se nota.
Estados de una vista	Cómo se ve cuando carga (un indicador), cuando no hay datos (un mensaje y, si aplica, una acción) y cuando falla (el mensaje del back en un aviso). Los tres, iguales en todos los módulos.
Dónde viven los estilos	Los comunes, en `src/styles.css`. Los que solo usa un componente, en el CSS de ese componente.

Para la paleta, una forma simple de que todos usen los mismos colores es declarar una variable de CSS por color en src/styles.css y usarla desde cualquier componente:

:root {
  --color-principal: #1b4f72;
  --color-secundario: #f4d03f;
  --color-error: #c0392b;
}

6. Paso 5: el prototipo nuevo y la wiki

Con todo lo anterior, el equipo construye un prototipo nuevo: HTML con Bootstrap, sin Angular. Es el prototipo que se publica, y reemplaza a los de la semana 1.

Debe mostrar, como mínimo:

El layout del paso 2, con el menú del paso 3.
Una vista de lista, una de detalle y una de formulario, tomadas de los módulos del grupo.
Los estilos del paso 4 y los tres estados de una vista: cargando, sin datos y con error.
Navegación que funciona: el menú y los enlaces entre vistas llevan de una página a otra. Puede ser un archivo por vista, con el mismo menú copiado en cada uno, o un solo archivo con enlaces a secciones.

Para que funcione sin instalar nada, el prototipo carga Bootstrap desde un CDN:

<link
  href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.8/dist/css/bootstrap.min.css"
  rel="stylesheet">

Los archivos van en la carpeta docs/ del repositorio del grupo, como en la semana 1. Por ejemplo, docs/prototipo/index.html, docs/prototipo/lista.html, docs/prototipo/detalle.html y docs/prototipo/formulario.html.

La página de la wiki, que se llama “Diseño de la interfaz”, tiene:

El enlace al prototipo en docs/ y una captura de cada vista.
El app.html del paso 2, con sus <router-outlet>.
La decisión del menú (global o por módulo, con sus ítems) y la vista por defecto, con su justificación según los usuarios y los objetivos.
La tabla de rutas del paso 3.
La guía de estilo del paso 4.

Nadie empieza el front del Release 8 hasta que esa página esté aprobada por todos los integrantes. Lo acordado no se vuelve a discutir al escribir el código: si algo no funciona, se cambia la página primero y después el código.

IA permitida aquí: una vez que el equipo decidió el layout, el menú y la guía de estilo, puede pedirle a Gemini que genere los archivos HTML del prototipo a partir de esas decisiones. El equipo revisa que el prototipo muestre lo acordado y no lo que la IA prefirió, y que la navegación entre las páginas realmente funcione.

7. Errores frecuentes

Un menú con un ítem por módulo sin pensar en el usuario. Refleja cómo se repartió el trabajo del equipo, no cómo usa la aplicación quien la abre.
Dejar la vista por defecto sin decidir. Al entrar a / no se ve nada, o se ve la vista del primero que escribió la ruta.
Una tabla de rutas incompleta. Faltan las vistas de asociación o la ruta de respaldo, y aparecen tarde, cuando dos integrantes las escriben distinto.
Estilos en cada componente. Cada módulo termina con su propio azul y su propio botón.
Un prototipo que no navega. Las capturas se ven bien pero nadie comprobó que el menú lleva a donde dice.
Empezar a construir el layout antes de la aprobación. Cambiar el diseño después obliga a rehacer app.html y los estilos de todos.

8. Cierre

Antes de dar el taller por terminado, el equipo revisa esta lista:

Cada integrante mostró su prototipo de la semana 1, y el equipo anotó qué conserva y qué descarta.
El layout está definido, con el o los <router-outlet> y el comportamiento en pantalla pequeña.
El menú principal responde a los objetivos y a los usuarios de la aplicación, y la vista por defecto está decidida.
La tabla de rutas tiene una fila por cada vista, incluidas las de asociación y la ruta de respaldo.
La guía de estilo tiene paleta, tipografía, componentes, estados y dónde viven los estilos.
El prototipo en HTML está en docs/ y su navegación funciona.
La página “Diseño de la interfaz” está publicada en la wiki y todos los integrantes la aprobaron.

Con eso aprobado, el equipo empieza el Release 8 por el tutorial de rutas y menú, que construye el Router y el menú que acaban de diseñar.