Especificación del micrositio

Este documento define qué se construye y por qué. Las decisiones cerradas están en la sección 7 y las abiertas, en Capa de revisión: decisiones y recomendaciones.

---

0. Problema, usuarios y criterio de éxito

Problema. Las ayudas actuales tienen dos puertas de entrada que compiten entre sí, mezclan aprender con consultar, no tienen explicaciones conceptuales y no atienden al perfil Admin. Antes de editar la wiki real hace falta poder ver y recorrer la nueva organización tal como se vería en producción.

Usuarios del micrositio.

1. Equipo de revisión de la wiki: evalúa la propuesta y la aprueba.
2. Alumnos y profesores: participan en un test corto de hallazgo de información.

Criterios de éxito.

• Aprobación: el equipo de revisión recorre el sitio y aprueba la arquitectura, la ficha y los componentes, o devuelve observaciones concretas.
• Test con 3 a 5 personas: al menos el 80 % completa 4 tareas sin ayuda, en 3 clics o menos desde la barra superior. Las tareas son: solicitar una cuenta, crear su Persona, subir un archivo y entender la diferencia entre Persona y Usuario.
• Fidelidad: quien usa Casiopea a diario no percibe diferencias entre el chrome del micrositio y el de la wiki real (cabecera, menús, pie, tipografía, modo claro y oscuro, móvil).
• Portabilidad: cada página del micrositio se puede convertir en una página de la wiki sin rediseñarla, porque usa solo componentes que existen en la wiki o que se especifican como plantillas nuevas.

Fuera de alcance. Edición, búsqueda real, inicio de sesión y consultas #ask en vivo (se simulan con datos estáticos). Las páginas que no son de ayuda enlazan a la wiki real.

---

1. Qué se clona

Regla: el CSS de la skin se usa tal cual. Lo nuevo (ficha y componentes) va en hojas aparte y consume solo tokens semánticos var(--sn-*), con las restricciones de TemplateStyles (sin valor de respaldo en var(), sin :focus-within, sin var() dentro de transition). Así cada componente se puede llevar a Plantilla:X/style.css. Detalle en Sistema de diseño de las ayudas.

---

2. Arquitectura de información

2.1 Cambio en la barra (menú «Wiki»)

Un solo punto de entrada, más «Empieza aquí» como atajo para quien llega por primera vez. Los títulos antiguos (Ayuda:Nuevo Usuario, Ayuda:Cómo editar la Wiki) pasan a ser redirecciones, para no romper enlaces.

2.2 Portada de ayudas (Ayuda:Portada)

Tres formas de entrar, de la más guiada a la más directa:

1. ¿Quién eres? El perfil es una pista, no una barrera: Lector, Alumno, Profesor, Administrador o Mantenedor. Cada opción muestra su recorrido recomendado (3 a 5 páginas en orden) sin esconder el resto.
2. ¿Qué necesitas? Los cuatro modos de Diátaxis:
   • Aprender (tutoriales): «Te llevamos paso a paso.»
   • Resolver (guías): «Tienes una tarea concreta.»
   • Consultar (referencias): «Buscas un dato exacto.»
   • Entender (explicaciones): «Quieres saber por qué funciona así.»
3. ¿Sobre qué? Por tema: Cuenta y acceso · Persona · Páginas y edición · Archivos y multimedia · Semántica y datos · Interfaz y diseño · Administración · Transversal.

Además: ayudas en preparación, una línea de contacto (wiki@ead.cl) y enlaces a la wiki real.

Profundidad: Barra → Portada → Página (2 clics). Las vistas por modo y por tema son filtros del mismo catálogo y nunca agregan un tercer nivel.

2.3 Modelo de contenido: Diátaxis sobre Tipo de Documento

No se crea una propiedad nueva. El modo se deriva del tipo:

Las guías que hoy viven en Ayuda: se reclasifican: las de paso a paso quedan como Resolver; las de tablas o sintaxis pasan a Documentación: como Consultar.

2.4 Catálogo

El catálogo completo, con el origen de cada página y sus cambios, está en Árbol completo de ayudas. Resumen: 38 ayudas con estructura y 18 pendientes (F1 a F18), 56 nodos en total.

2.5 Circuitos (reglas de enlace)

Cada página cumple lo siguiente:

• Ruta: «Antes» (prerrequisito) y «Después» (siguiente paso), tomados de la ficha.
• Puente de modo: al menos un enlace a otro modo. Una guía enlaza a su referencia («ver todos los campos») y a su explicación («por qué se pide esto»).
• Salida a la wiki real: al menos un ejemplo vivo o una herramienta (formulario, Especial:Subir).
• Ninguna página queda huérfana: la portada, una vista por modo o una vista por tema la enlazan.

---

3. Ficha de documentación v0.4

La versión detallada (tres capas, variantes y distribución por modo) está en Inventario y propuesta de ficha §3 y §4. Se mantienen las 12 propiedades de Plantilla:Documentación de Casiopea y se agregan tres parámetros de presentación, que no son propiedades SMW:

Ubicación: una banda compacta bajo el título; «Antes / Después / En otros modos» se repite como pie de navegación. Se corrigen además las Palabras Clave con valores canónicos y se elimina el <div style> en línea.

---

4. Componentes

El inventario completo, con su base en la skin, su uso, su justificación y lo que falta evaluar, está en Sistema de diseño de las ayudas y en el espécimen del sitio. Resumen:

---

5. Criterios de redacción

Generales: se le habla a la persona de «tú», con palabras comunes antes que técnicas. Párrafos de 3 líneas como máximo, frases de unas 20 palabras, una idea por párrafo. La primera línea dice qué se logra.

Por perfil:

• Alumno: ejemplos de tareas y proyectos; no se presupone vocabulario técnico (se apoya en las definiciones en línea).
• Profesor: foco en el curso y en el seguimiento de los alumnos; atajos.
• Administrador y Mantenedor: precisión técnica; nombres reales de páginas Especial: y advertencias de impacto.

Etiquetas: cortas y que empiezan por la acción. Las tarjetas no repiten «Aprende a…».

---

6. Enfoque técnico

• Repositorio casiopea-ayudas en GitHub, conectado a Vercel: cada push a main se publica.
• Generador estático propio (build.mjs, Node con marked y js-yaml). Reproduce el chrome capturado de la wiki y genera:
  • las páginas de ayuda desde data/nodos.yml (la ficha es el registro de cada nodo);
  • las vistas por modo, perfil y tema (lo que en la wiki serían consultas #ask);
  • el área Proyecto desde docs/ (notas de Obsidian con frontmatter) y desde data/revision.yml, data/gantt.yml, data/glosario.yml e data/incrustables.yml;
  • el espécimen de componentes.
• Rutas relativas: el sitio se abre también sin servidor, desde la carpeta generada.
• Revisión: vista previa de Vercel por cada cambio.

---

7. Decisiones cerradas

Pendiente e importante: la reformulación de las audiencias (D-09).

---

8. Ayudas pendientes y fuentes

• Ayudas pendientes: 18 ayudas que faltan (F1 a F18) se muestran como páginas pendientes: ficha con sello «Pendiente», aviso «Mientras tanto» y especificación plegada. Se reúnen en Documentación:Ayudas por escribir y en un bloque de la portada. Detalle en Ayudas que faltan.
• Ficha: se propone el valor Pendiente para Estado (D-08).
• Fuentes de contenido: la base factual es la documentación oficial de cada programa en su versión instalada (MediaWiki 1.43, SMW 6.0.1, Page Forms 6.0.5, SRF 5.2.0, Maps 12.1.4, Stella Nova 0.9.0). El contexto se toma del snapshot de Casiopea y la forma, de Diátaxis. Se adapta, no se copia, y cada página cita sus fuentes al pie. Reglas completas en Ayudas que faltan §1.4.
• Incrustar contenido: el catálogo de widgets y extensiones (data/incrustables.yml) alimenta las guías 12, 13 y 42, la referencia 23 y la pendiente F18.

---

9. Grupo «Interfaz y diseño»

Criterio: las plantillas, los formularios y las propiedades son funciones de SMW, Page Forms y MediaWiki, y en Casiopea solo puede usarlas un administrador. Casiopea no reescribe su documentación: muestra qué se puede hacer, para qué sirve y quién puede hacerlo, deriva a la documentación oficial y convierte a quien quiere ir más allá hacia la administración. Patrón completo en Árbol completo de ayudas §7.

Conversión: el bloque «¿Quieres ser administrador de Casiopea?» lleva a F17 Ser administrador de Casiopea (pendiente) y, mientras tanto, a Casiopea:Solicitudes. Falta definir el proceso para llegar a ser administrador (D-07).

Contenido previsto para 39 · Por qué trabajar con tokens

1. La idea en una frase: un token es un nombre con intención (por ejemplo, --sn-ink, «la tinta del texto») en lugar de un valor fijo (#1a1a1a).
2. Para qué sirve:
   • Modo claro y oscuro sin trabajo extra: el token cambia de valor según el tema y el color fijo no. El ejemplo real son las tarjetas que hoy se rompen en modo oscuro.
   • Coherencia: toda la wiki habla el mismo idioma visual que la skin.
   • Mantención: un cambio en tokens.css actualiza todas las páginas a la vez.
   • Accesibilidad: las combinaciones de tokens ya están pensadas para tener contraste suficiente.
   • Durabilidad: si la skin cambia de versión, las páginas que usan tokens siguen funcionando.
3. Las tres capas (primitivas, semánticas y de componente) y por qué casi siempre se trabaja con la capa semántica.
4. Por qué sin valor de respaldo: el sanitizador de TemplateStyles lo rechaza y, además, ocultaría los errores.
5. Ejemplo en la wiki real: una plantilla tokenizada frente a una que todavía usa colores fijos.
6. Para ponerlo en práctica: 38.

---

10. Capa de revisión

• Marcador de revisión, en línea, con dos variantes: Decisión (?, en ámbar: algo que otra persona o equipo tiene que resolver) y Recomendación (✦, con borde: una propuesta con su fundamento). Al abrirlo muestra ID, texto, fundamento u opciones, responsable (por rol), estado, impacto y fuente.
• Accesible: es un <button> con aria-expanded; se abre con clic, toque o teclado (no con hover), se cierra con Escape y en móvil se abre como panel inferior. Nunca se distingue solo por color.
• Interruptor «Revisión»: encendido durante la revisión y apagado en el test con usuarios (?revision=0). También controla el aviso de componente nuevo.
• Vista agregada: página Decisiones, filtrable por responsable y estado.
• Registro único (data/revision.yml): cada marcador se declara una vez y en el texto se cita por ID. Hoy reúne 15 decisiones, 16 recomendaciones y 7 propuestas de cambio. Detalle en Capa de revisión: decisiones y recomendaciones.
• Llevar la capa a la wiki real queda como propuesta de cambio P7, para evaluarla después de probarla en el micrositio.

---

11. El sitio es la documentación

El micrositio no es solo el prototipo de las ayudas: es la documentación del proyecto. Los documentos de diseño se publican como páginas del sitio, de modo que la propuesta, su fundamento, sus decisiones y su planificación se recorren en un solo lugar.

11.1 Dos áreas en un mismo sitio

11.2 Páginas del área Proyecto

11.3 Carta Gantt

• Se genera desde data/gantt.yml, igual que la capa de revisión.
• Las decisiones aparecen como bloqueos de las tareas que dependen de ellas.
• Muestra prioridades (Alta, Media, Baja), responsables por rol, fases y la carga semanal frente a la capacidad.
• Usa los tokens de Stella Nova, es legible en modo claro y oscuro, y en móvil se convierte en una lista.

11.4 Fuente única

El repositorio es la fuente de verdad del área Proyecto. Cualquier otra copia de estos documentos es de respaldo y se actualiza desde el repositorio, no al revés.