⚙️ Configuración general: decisiones que se toman una vez

🧠 La configuración general: decisiones que se toman una vez

Todo lo que se define en la pestaña Configuración lo heredan las aulas y lo respiran los usuarios: la identidad visual, los idiomas, los campos que describen a cada persona, los roles con sus permisos, el comportamiento por defecto de cada aula nueva. Es el nivel donde las decisiones institucionales se vuelven configuración — y por eso es el paso previo lógico a crear la primera aula: un campus bien configurado hace que cada aula nazca bien configurada.

La pestaña se organiza en los menús General, Apariencia (Principal y Portada), Defaults (con sus subsecciones: Aula, Secciones, Usuarios, Permisos, Certificados, Clases y Evaluaciones), Datos de usuario, Editor, Sucesos y Notificaciones. En algunos campus aparece además Empresas, para la segmentación de usuarios por organización: el conjunto exacto de menús y subsecciones depende de la versión y los productos de cada proyecto.

La pestaña Configuración con sus menús. El conjunto puede variar entre campus: no todos incluyen, por ejemplo, Empresas.

🧭 Criterios de uso

• Primero el campus, después las aulas. Ajustar la configuración general con el proyecto ya definido evita corregir aula por aula lo que pudo decidirse una sola vez.
• Los datos de usuario se diseñan para cada propuesta. Los campos prearmados cubren lo genérico; el diseño real está en sumar los datos que la propuesta necesita — y en elegirles el tipo de ingreso pensando en cómo se van a procesar después.
• Los permisos son la definición operativa de los roles. Nombrar los perfiles con las palabras del proyecto y definir qué puede cada uno, sección por sección, es diseñar cómo va a funcionar el equipo — no un trámite técnico.
• Los Defaults son la política del proyecto. Cada opción por defecto bien pensada es una decisión que nadie tendrá que recordar en el alta del aula 47.
• Las secciones se nombran una vez, para todo el campus. Que todas las aulas llamen igual a las mismas secciones hace que tutoriales, soporte y usuarios hablen el mismo idioma; el renombre por aula queda para la excepción justificada.
• Los sucesos se configuran como una cartelera. Anunciar lo que estructura y convoca, silenciar el detalle: demasiados avisos convierten las novedades en ruido.
• Las piezas gráficas, con sus medidas antes de empezar. Tres logos con destinos y tamaños distintos, la imagen de portada con el suyo: preparar los archivos con las especificaciones a la vista ahorra idas y vueltas.
• Cambiar la configuración general es cambiar la experiencia de todos. A diferencia del aula, acá no hay ensayo acotado: conviene documentar qué se cambia y por qué.

🪪 Identidad del campus

General

Los datos globales de la plataforma: el nombre de la institución con su URL, el Administrador general del campus y los Idiomas activos — que son los que luego cada aula puede adoptar, o imponer sobre la preferencia del usuario.

Apariencia > Principal: la identidad gráfica

• Tres logos, cada uno con su destino y su medida: el Logo principal (el del encabezado, arriba a la izquierda en la vista de usuario — recomendado 112 × 72 px), el Logo email (el que viaja en cada correo enviado desde la plataforma — 101 × 63 px) y el Icono o favicon (el de la pestaña del navegador — 32 × 32 px). Para cada uno: mantener el actual, cambiarlo, o volver al logo por defecto.
• Skin: la apariencia gráfica externa del campus. Se dispone del skin base AXIS; si el proyecto tiene un skin personalizado, aparece también en el selector.
• Color (uno solo): define la gama que toman el encabezado, la pantalla de Login y la de Aulas, elegido de una paleta predefinida. La recomendación oficial: tonos medios u oscuros, porque sobre ellos van textos e imágenes claras.

Apariencia > Principal: los tres logos con sus medidas recomendadas y el patrón mantener / cambiar / por defecto, el skin del proyecto y el color del campus.

Apariencia > Portada: la cara del Escritorio

• Título (opcional) y Estilo, con tres opciones: solo contenido, imagen de fondo y contenido, o solo imagen de fondo.
• Contenido: la imagen (620 × 450 px, en GIF, JPG o PNG) y el editor para el contenido HTML.
• Vínculos: los enlaces a URLs externas que se mostrarán en el Escritorio — el lugar para el sitio institucional, la mesa de ayuda, los reglamentos.

🔔 Comunicación y registro

Editor

La configuración del editor de textos que usan todas las secciones del campus: los comportamientos de hipervínculos, la inserción de imágenes y las demás opciones de edición, definidos una vez para toda la plataforma.

Sucesos: decidir exactamente qué se anuncia

Los sucesos son el registro de novedades que los usuarios ven en el escritorio del campus y en la página de inicio de cada aula: "se publicó tal contenido", "se abrió tal debate". Son la cartelera automática de la plataforma — y como toda cartelera, funciona si anuncia lo que importa y calla lo que no.

La configuración lo decide tipo de contenido por tipo de contenido: para tópicos, unidades, textos, materiales de estudio, paquetes SCORM, actividades, temas de debate, evaluaciones, encuestas y recursos LTI, se define si el suceso se genera siempre o nunca. Es una decisión editorial, no técnica: anunciar la apertura de cada unidad y de cada debate marca el ritmo del cursado; anunciar cada texto y cada archivo convierte la cartelera en ruido — y el ruido silencia lo importante.

La configuración de sucesos, tipo por tipo. En el ejemplo, una política selectiva: se anuncian las unidades y los temas de debate — lo que estructura y convoca — y se silencia el resto.

Notificaciones

Los avisos generales a nivel plataforma: se muestran en el escritorio a todos los usuarios por igual, de a una — primero la más reciente —, y cada usuario las va cerrando con la X a medida que las lee. Solo los webmasters pueden gestionarlas, y al ser de plataforma no se ven afectadas por los respaldos de aulas o unidades. Es el canal para lo que todo el campus debe saber: un mantenimiento programado, un cambio de calendario, un anuncio institucional.

🧬 Datos de usuario: diseñar los campos de cada propuesta

Los datos disponibles vienen organizados por categorías — Contacto, Social, Estudio, Trabajo, Personal, Favoritos, Redes sociales y Contenidos —, cada uno con su estado: activado o no para el uso en el campus. Pero activar y desactivar campos prearmados es solo la mitad del trabajo. Cada propuesta formativa necesita saber cosas distintas de sus cursantes: una formación docente de alcance nacional necesita provincia, cargo e institución de desempeño; un posgrado, la titulación de base; una capacitación corporativa, el área y la sede. El diseño real está en sumar los datos adicionales que la propuesta exige, no en conformarse con los que vienen.

Agregar un dato adicional

Se define su categoría (dónde aparecerá en la ficha del usuario), el nombre, una descripción opcional, el tipo de ingreso — texto corto, lista de opciones y demás variantes — y su estado.

El alta de un dato adicional — en el ejemplo, "Provincia" en la categoría Contacto — con la advertencia de la plataforma a la vista: al guardar, el tipo de dato no podrá modificarse.

Estos campos reaparecen en toda la plataforma: en la ficha de cada usuario, en la columna adicional de Contactos, en las variables de personalización de los avisos, en las importaciones y los reportes. Por eso se diseñan mirando el proyecto: qué necesita saber la institución de sus cursantes, y qué va a hacer con eso.

🔑 Permisos: nombrar los roles y definir qué puede cada uno

Los perfiles del campus no vienen con nombres fijos: los nombra el proyecto. Cursantes, Tutores, Coordinadores, Responsables de contenido, Equipo, Invitados — o los que la institución use en su vida real. El nombre importa: es la palabra con que el campus le habla al equipo, y conviene que coincida con cómo el proyecto llama a sus roles, no con una jerga técnica ajena.

Para cada perfil se define su estado y, sección por sección, el nivel de permiso: qué ve, en qué participa, qué puede cargar, qué administra. Esa grilla es la definición operativa de cada rol — el organigrama del proyecto hecho configuración. Un tutor que no puede cargar contenidos, un responsable de contenido que no califica, un invitado que solo lee: cada columna de la grilla es una descripción de puesto.

La grilla de permisos por perfiles: los nombres los pone el proyecto — acá, Cursantes, Tutores, Coordinadores, Responsables de contenido, Equipo, Invitados — y cada columna define, sección por sección, qué puede ese rol.

🏗️ Defaults: la política del proyecto

El menú Defaults define con qué configuración nace lo que se crea de ahí en adelante, en sus subsecciones: Aula (la configuración completa del aula nueva, color incluido), Secciones (cuáles nacen activas, en qué orden y con qué nombre — ver abajo), Usuarios (las preferencias iniciales, como el resaltado de contenidos no leídos o la visibilidad de los datos personales), Permisos (la grilla recién vista), Certificados, Clases (el comportamiento del Programa) y Evaluaciones.

Los Defaults con sus subsecciones a la vista. En pantalla, la configuración de usuarios: el resaltado de contenidos no leídos y la visibilidad de los datos personales con que nacerá cada usuario.

Bien definidos, los defaults convierten cada alta en un trámite: si expresan las decisiones institucionales, crear un aula es ponerle nombre y contenido, no revisar cuarenta opciones.

Las secciones: activar, ordenar y — sobre todo — nombrar

En Defaults > Secciones, cada sección del aula tiene su estado (activa o no), su orden (se arrastra) y su nombre, que se edita haciendo clic sobre él. Y el nombre es la decisión más visible de todas: es la palabra que el cursante lee en el menú del aula todos los días. La misma sección puede llamarse Clases en un campus y Programa en otro; Encuestas o Formularios; Archivos o Materiales.

El criterio: los nombres se definen acá, para todo el campus, y la coherencia es la regla. Que todas las aulas llamen igual a las mismas secciones hace que los tutoriales sirvan para todos, que el soporte hable el mismo idioma que los usuarios, y que quien cursa dos propuestas no tenga que retraducir el menú. Algún aula puede renombrar una sección para su propuesta particular — está permitido y a veces se justifica — pero eso debe ser la excepción documentada, no la costumbre de cada creador de aulas.

Las secciones definidas: estado, orden arrastrable y nombre editable con un clic. En este campus, la sección de contenidos se llama Clases...

...y en este otro, Programa. Mismo componente, nombre institucional distinto: la decisión se toma una vez, acá, y todo el campus la hereda.

El sentido de todo el menú es uno solo: configurar una vez, heredar muchas. Cada opción bien pensada acá es una decisión que nadie tendrá que volver a tomar en el alta del aula 47. Con dos salvedades que conviene tener presentes: los defaults se aplican a lo que se crea desde cero — un aula duplicada hereda la configuración del aula de origen, no estos valores —, y el idioma predeterminado del campus vive justamente acá, en Aula y en Usuarios.