Wiki Casiopea: hacer visible lo colectivo

Resumen

Este no es un proyecto con fecha de entrega. Es un rol de diseño activo y remunerado sobre una plataforma real, con usuarios reales, que lleva activa 17 años. Comenzó como proyecto de título en el Taller Casiopea 2024 y mutó en un cargo permanente como Diseñadora de Experiencia y Arquitectura de Información de Wiki Casiopea, en la Escuela de Arquitectura y Diseño de la PUCV.

Casiopea es la memoria digital colectiva de la escuela: miles de páginas con tesis, proyectos, registros de travesías, revistas, artículos y bitácoras de cursos, bajo una filosofía heredada de la Ciudad Abierta de Amereida — sin jerarquías, sin candados, creación colectiva. El problema era que esa horizontalidad, sin traducción para el usuario, se experimentaba como caos. Mi trabajo fue encontrar la forma de hacer visible esa estructura sin traicionarla.

Origen

Proyecto de Título 2024

Taller Casiopea · e[ad] PUCV · Tutores Herbert Spencer y Katherine Exss. Investigación de usuarios, diseño de plantillas de objetos semánticos, onboarding y documentación.

Estado actual

Ayudante Casiopea — rol permanente

Gestión continua de la plataforma, creación de usuarios, capacitaciones, reportes de actividad, mejoras de interfaz e implementación frontend (CSS/JS).

Lo que distingue este case study de la mayoría: no es un prototipo en Figma. Es una plataforma en producción con 150 usuarios creados, 154 horas de trabajo documentadas y un reporte anual con datos reales de uso. El trabajo de diseño ocurre dentro de un sistema vivo, con restricciones técnicas reales y consecuencias directas sobre una comunidad académica de cientos de personas.

Etapa 1. Auditoría de usabilidad

La tensión de fondo

Ciudad Abierta digital vs. accesibilidad cognitiva

Casiopea hereda la filosofía de la Ciudad Abierta de Amereida: horizontalidad, hospitalidad, creación colectiva. En términos técnicos, todas las páginas tienen la misma jerarquía — no hay árbol de navegación, no hay dependencias. Puedes navegar la wiki completa sin ser usuario, ver el historial de cada edición, leer desde los textos fundacionales de la escuela hasta la bitácora de una clase de primer año, ver el avance de una tesis a lo largo de semestres, acceder a revistas (Acto y Forma), travesías, proyectos de titulación y registros de investigación.

El problema: sin jerarquía visible, el usuario nuevo no sabe qué tipo de objeto está mirando, qué puede editar ni cómo contribuir. La apertura se experimentaba como desorientación.

Investigación de usuarios — métodos aplicados

La investigación fue realizada en conjunto con Francisca Ortega y Scarleth Osorio (compañeras del Taller Casiopea). Se aplicaron tres instrumentos: encuesta con escala de Likert a 60 estudiantes (32 de Arquitectura, 28 de Diseño), entrevistas semi-estructuradas a alumnos y profesores, y partituras de interacción que mapearon 4 viajes de usuario clave.

Hallazgo clave por carrera

• Diseño — actitud mayormente positiva: Valoran la wiki como herramienta de información y toma de decisiones curriculares. Su mayor fricción es la usabilidad al editar, no la comprensión del valor de la plataforma.

• Arquitectura — actitud mayormente negativa: Uso más acotado, ediciones más escuetas. La falta de uso genera chatarra espacial: páginas duplicadas, archivos sin enlazar, información perdida. La brecha entre carreras es un problema operativo concreto.

Usos principales identificados

Los estudiantes usan la wiki principalmente para subir tareas (23,8%), ver el trabajo de compañeros (23,8%) y elegir talleres y asignaturas (19,4%). El uso es casi exclusivamente académico y dirigido por requerimientos docentes — no hay contribución espontánea.

Hallazgo contradictorio

Los estudiantes que dicen encontrar difícil la wiki tienen conocimiento previo de Wikipedia y herramientas de edición de código. Esto indicó que el problema no era de desconocimiento tecnológico sino de usabilidad específica de la plataforma — una distinción importante para definir el tipo de solución.

Cita de entrevista

"...entonces hago toda una búsqueda de ese código o busco en internet cómo hacer esto en CSS... es como bien tedioso, cuando a lo mejor la wiki podría decirte: si quieres hacer un margen, aprieta este botón."

Partituras de interacción

Se mapearon 4 viajes de usuario como método previo al wireframing: ingreso a cuenta (caso exitoso y caso de error), acceso a la página del taller, creación de una tarea, y adición de un widget de PDF. Las partituras visualizaron los quiebres de experiencia concretos en cada flujo — puntos donde el sistema no responde como el usuario espera — y sirvieron de base directa para las propuestas de diseño.

Etapa 2. Estrategia de diseño

Hipótesis

Si se diferencia visualmente cada tipo de objeto semántico — sin cambiar la arquitectura plana de la wiki — el usuario puede orientarse dentro de la horizontalidad sin necesidad de una jerarquía impuesta. El contexto local de cada página reemplaza la necesidad de un árbol de navegación global.

Tres estrategias simultáneas

• Contexto local en cada página: Cada plantilla de objeto semántico comunica inmediatamente qué tipo de página es y qué puede hacer el usuario desde ahí. La jerarquía es perceptual, no estructural. La horizontalidad rizomática se mantiene intacta.

• Onboarding antes de entrar: Páginas de ayuda y guías diferenciadas por perfil (estudiante nuevo, profesor nuevo) que explican el modelo mental de la wiki antes de que el usuario tenga que descubrirlo solo.

• Documentación dentro de la wiki: Todo el proceso de creación y mantenimiento de plantillas documentado en Casiopea, para que futuras generaciones puedan continuar sin depender de una persona específica.

Lo que decidí no hacer

No introduje jerarquías de navegación verticales ni estructuras de árbol. En Casiopea, la bitácora de un estudiante de primer año y el artículo de un profesor titular comparten el mismo nivel porque ambas voces tienen el mismo valor. Imponer una estructura arbórea habría resuelto la desorientación del usuario a costa de traicionar la filosofía que hace única a la plataforma.

Revisión de referentes

Se analizaron TiddlyWiki, DokuWiki y Obsidian — tres wikis con enfoques distintos de diferenciación visual y accesibilidad editorial. El foco no era copiar soluciones sino entender qué estrategias existen para hacer legibles plataformas de conocimiento no jerárquico.

Etapa 3. Desarrollo del prototipo

Mi rol técnico — precisión importante

La skin de Casiopea — paleta institucional, tipografía y estilos base — es un sistema preexistente definido en la CSS de la plataforma, anterior a mi rol. Mis intervenciones técnicas han sido de usabilidad: creación de componentes nuevos dentro de ese sistema (acordeones, plantillas de objetos semánticos, rediseño de páginas de ayuda) usando CSS/JS donde la plataforma lo permite, sin modificar la CSS global por razones operativas.

Componentes desarrollados

• Plantillas de objetos semánticos. Fichas diferenciadas para Persona, Curso, Proyecto, Tarea y Travesía. Cada una con jerarquía visual propia que comunica el tipo de contenido desde el primer vistazo, usando los atributos de Semantic MediaWiki. Estas plantillas son el núcleo del proyecto: son instrucciones que se ejecutan cada vez que alguien publica, no pantallas estáticas.

• Card grid con hover GIF. Tarjetas con imagen estática que se activa como animación al hacer hover. Problema técnico: hover GIF y tarjeta completamente clickeable eran incompatibles en CSS puro por conflicto de z-index. Solución: delegación de eventos en MediaWiki:Common.js.

• Acordeón con jQuery. Para agrupar contenido extenso en páginas de ayuda. Primer ítem abierto por defecto. Resuelve páginas de tutoriales que antes eran muros de texto continuos sin estructura scaneable.

• Páginas de ayuda rediseñadas. Nuevo Usuario, Tutoriales Nuevo Profesor, solicitud de cuenta y documentación de widgets. Todas con lenguaje cercano, acciones concretas y visibles, y estructura por perfil de usuario.

Restricciones técnicas del entorno

• MediaWiki elimina <script> en páginas. Todo JavaScript debe ir en MediaWiki:Common.js. No es posible escribir scripts inline en el contenido de una página.

• Indentación en HTML = código preformateado. Los espacios al inicio de línea son interpretados como bloques de código. El HTML debe escribirse sin ninguna indentación.

• H1 automático de MediaWiki. MediaWiki genera el título de la página como H1 automáticamente. Solución: __NOTITLE__ + h1 manual para controlar la semántica tipográfica de cada página.