Ficha técnica

Enfoque metodológico

Este curso no enseña a programar. Enseña a dirigir a una IA que programa por ti.

El punto de partida es una idea incómoda para muchos docentes: durante años, crear un recurso digital interactivo exigía dominar HTML, CSS y JavaScript, y esa barrera dejaba fuera a la mayor parte del profesorado. Hoy la situación es la contraria. La sintaxis la escribe la máquina; el docente aporta lo que la máquina no tiene: sabe qué necesita su alumnado. Ese es el reparto de tareas del curso.

La secuencia es siempre la misma, y se repite en cada taller hasta que sale sola:

1. Preparación — definir qué app quiero y para quién.
2. Generación — pedir el código con un prompt maestro bien estructurado.
3. Iteración — probar, copiar el error y pedir la corrección. Sin miedo.
4. Despliegue — publicar y obtener un enlace para el aula.

Hilo conductor. En la sesión 1 cada asistente elige una necesidad real de su aula y la convierte en el encargo de su aplicación. Esa app se construye, itera y publica a lo largo de las cuatro sesiones. Nadie sale con un ejemplo de manual: sale con un enlace que funciona y que puede usar el lunes.

Itinerario de la serie

Este curso forma parte de una serie de cuatro, todos independientes entre sí:

Ninguno exige haber cursado los anteriores. Haberlos cursado es una ventaja, porque se llega con soltura en la conversación con la IA, pero no un requisito de admisión.

SESIÓN 1 — De la idea a la app: el cambio de paradigma

Ficha técnica de la sesión

• Objetivo: entender el nuevo reparto de tareas, elegir una necesidad real del aula y llegar a ver en pantalla una primera aplicación funcionando.
• Estructura: 1 h de exposición dialogada + 2 h de taller práctico.
• Recursos: ordenador con Internet y cuenta de Gmail, navegador actualizado.

1. Parte teórica (60 min)

A. Qué es una aplicación web educativa y para qué sirve de verdad (20 min)

• No es una presentación ni un PDF. Es un recurso que hace cosas: pregunta, corrige, cuenta aciertos, simula, ordena, calcula.
• Ventaja práctica sobre cualquier otra herramienta: se reparte con un enlace o un código QR. No se instala, no se descarga, funciona en el móvil, la tablet o el portátil del alumno, y funciona también desde casa.
• Ejemplos que se hacen en este curso: una batería de flashcards autocorregibles, un simulador sencillo con deslizadores, una calculadora de notas, un trivial de repaso, un glosario con buscador.

B. El nuevo reparto de tareas: tú diriges, la IA pica el código (20 min)

• Lo que ya no hace falta: memorizar etiquetas, cerrar llaves, buscar el punto y coma que falta. Esa carga técnica desapareció para el docente.
• Lo que sigue siendo tuyo y no se delega: saber qué necesita tu grupo, decidir qué es evaluable, comprobar que el resultado enseña algo. La IA no conoce a tu alumnado.
• Consecuencia: el cuello de botella ya no es la sintaxis, es la claridad de la petición. Quien describe bien su app, obtiene su app.

C. Las cuatro fases del método (20 min)

Mensaje de la sesión: el error no es un fracaso, es la materia prima de la siguiente instrucción.

2. Parte práctica (120 min)

Taller 1 — De la necesidad a la app (30 min)

Cada asistente identifica una necesidad real de su aula y la escribe en una ficha:

• Qué problema tiene (ej. "los alumnos no retienen el vocabulario de la unidad").
• Para qué curso y cuántos alumnos.
• Qué debería hacer la app (ej. "mostrar una palabra, dejar responder y corregir al instante").
• En lenguaje natural, sin una línea de código.

La ficha se recoge y se devuelve en la sesión 2. Es el encargo de todo el curso.

Taller 2 — El prompt maestro arquitectónico (45 min)

Se presenta el marco R-T-C-F (Rol, Tarea, Contexto, Formato) y cada asistente lo rellena para su app:

[ROL] Actúa como desarrollador web senior especializado en tecnología educativa
y accesibilidad.

[TAREA] Crea una aplicación web completa que [QUÉ HACE TU APP].
Debe permitir [INTERACCIÓN 1], [INTERACCIÓN 2] y mostrar [RESULTADO].
Incluye un módulo de autoevaluación con preguntas y retroalimentación explicativa.

[CONTEXTO] La usarán alumnos de [NIVEL] en [DISPOSITIVO]. Trabajan sobre
[ASIGNATURA y TEMA]. Debe funcionar sin servidor ni conexión a servicios externos,
guardando el progreso en el almacenamiento local del navegador.

[FORMATO] Devuelve un ÚNICO archivo llamado index.html, completo y funcional,
con los estilos y el JavaScript dentro del propio archivo. Sin marcadores de
posición ni fragmentos pendientes. Devuelve solo el código, sin explicaciones.

Taller 3 — Primera generación guiada (45 min)

• Pegar el prompt en ChatGPT o Gemini y obtener el código.
• Guardarlo como index.html y abrirlo con doble clic en el navegador.
• Objetivo del día: ver algo funcionando en pantalla. Aunque sea feo, aunque falle algo.
• Recogida de los primeros fallos reales en la pizarra: sirven de material para la sesión 2.

3. Guía para el ponente

• Posible dificultad: asistentes que se quedan mirando el código como si fuera una escritura antigua.
• Cómo resolverlo: insistir en que no hace falta leerlo. El código es un archivo que se ejecuta, no un texto que hay que entender. Se lee el resultado, no el código.
• Punto de fricción real: guardar el archivo. En Windows, el Bloc de notas añade .txt al final y el archivo deja de funcionar. Hay que enseñar a elegir "Todos los archivos (.)" al guardar. Es el error número uno de la primera sesión.

SESIÓN 2 — Anatomía de la app y el arte del prompt

Ficha técnica de la sesión

• Objetivo: entender lo mínimo imprescindible de un archivo web, dominar el prompt maestro completo y aprender a iterar pegando el error en lugar de tocar el código.
• Estructura: 1 h de exposición + 2 h de taller.
• Recursos: la app generada en la sesión 1, plantilla de prompt maestro impresa y digital.

1. Parte teórica (60 min)

A. Qué hay dentro de un archivo HTML: lo mínimo para no perderse (25 min)

Tres partes, y ninguna más:

Por qué el curso trabaja siempre con un archivo único. Un index.html que lleva dentro sus estilos y su lógica no se rompe: no hay rutas relativas rotas, no hay archivos que se olvidan al copiar, no hay carpetas perdidas. Y las plataformas de publicación buscan exactamente ese nombre de archivo como puerta de entrada. Es la decisión de arquitectura más importante del curso y la que más disgustos evita.

B. Prompt suelto frente a prompt maestro (20 min)

La regla que se repite hasta que cansa: no pidas un botón, pide una aplicación con un propósito.

C. Accesibilidad: por qué pedir letra grande y contrastes fuertes es pedagogía, no estética (15 min)

• Botones con área táctil suficiente para dedos poco precisos o pantallas de móvil.
• Contraste de texto y color suficiente para quien tiene baja visión.
• Funcionar con teclado, no solo con ratón.
• Buena parte de estas mejoras benefician a todo el grupo, no solo al alumnado con necesidades específicas. Es el principio del Diseño Universal para el Aprendizaje: diseñar pensando en los extremos mejora la experiencia de todos.

2. Parte práctica (120 min)

Taller 1 — Arquitectura de archivo único (30 min)

Se reconstruye desde cero una mini app de ejemplo con el prompt maestro, para ver las tres partes del archivo en el código generado y comprobar que todo viaja dentro de un solo archivo.

Taller 2 — El prompt maestro completo (45 min)

Cada asistente lanza su prompt sobre su necesidad real, pero ahora con la plantilla completa: rol, tarea detallada, contexto de aula y restricciones de formato. Comparación en el proyector entre el resultado de la sesión 1 y el de ahora. La diferencia se ve.

Taller 3 — Iteración conversacional: copia el error y pégaselo (45 min)

El taller más importante del curso. El ciclo es siempre el mismo:

1. Probar la app y detectar qué falla exactamente ("el botón de comprobar no suma el acierto").
2. Encontrar la pista en el navegador: botón derecho → Inspeccionar → pestaña Console, y copiar el mensaje en rojo.
3. Pedir la corrección sin tocar el código a mano:

"El código que me diste presenta este error: [PEGAR EL MENSAJE DE LA CONSOLA O DESCRIBIR EL COMPORTAMIENTO]. Localiza la causa y devuélveme el archivo completo corregido, otra vez en un único index.html, sin explicaciones."

Ejercicio provocado: el ponente muestra cómo romper la app a propósito (cambiar una línea) y cómo la IA la repara. Se pierde el miedo a tocar.

3. Guía para el ponente

• Posible dificultad: asistentes que intentan leer y corregir el código a mano.
• Cómo resolverlo: prohibirlo explícitamente durante el taller. Toda corrección pasa por la conversación con la IA. Quien toca el código a mano se pierde y acaba bloqueado.
• Nota realista: puede que en este taller la app no quede perfecta. Está bien. La sesión 3 es para publicar y pulir, y nadie tiene que entregar nada hoy.

SESIÓN 3 — Publicar: del archivo al enlace

Ficha técnica de la sesión

• Objetivo: sacar la app del ordenador del docente y ponerla en un enlace que el alumnado pueda abrir hoy mismo.
• Estructura: 1 h de exposición + 2 h de taller de publicación.
• Recursos: cuenta de Cloudflare y cuenta de GitHub (se crean en el taller).

1. Parte teórica (60 min)

A. Qué es una web estática y por qué no hace falta servidor (15 min)

Nuestra app no consulta bases de datos ni guarda nada en la nube. Es un archivo que el navegador del alumno descarga y ejecuta en su propio equipo. Eso tiene dos consecuencias:

• Publicarla es casi gratis y casi instantáneo.
• Nada del alumnado sale de su dispositivo. La puntuación, el progreso y los aciertos se quedan en el navegador. Desde el punto de vista del RGPD, esto es una ventaja enorme y hay que decirlo en voz alta.

B. Las plataformas gratuitas, comparadas (25 min)

En ambos casos, el archivo debe llamarse exactamente index.html. Es la puerta de entrada que buscan las dos plataformas.

C. Del enlace al aula (20 min)

• Código QR para el alumnado: impreso en la ficha o proyectado. Es la vía más rápida en Secundaria.
• Enlace en el aula virtual o en la plataforma del centro.
• Qué NO se puede hacer con una web estática: recoger datos de alumnos, guardar resultados en un servidor, autenticar usuarios. Eso requiere backend y sale del alcance de este curso; conviene decirlo para no crear expectativas falsas.

2. Parte práctica (120 min)

Taller 1 — Publicar en Cloudflare Pages por arrastre (40 min)

1. Crear la cuenta gratuita.
2. Entrar en Workers y Pages → Crear aplicación → pestaña Pages.
3. Elegir Cargar directamente (Direct Upload).
4. Dar un nombre al proyecto: define el subdominio público.
5. Arrastrar la carpeta con el index.html y desplegar.

En segundos hay un enlace permanente con HTTPS. Cada asistente lo abre en su móvil.

Taller 2 — Publicar en GitHub Pages desde la interfaz web (40 min)

Sin terminal, sin git, todo con botones:

1. Crear un repositorio nuevo y marcarlo como público.
2. Add file → Upload files, arrastrar el index.html, Commit changes.
3. Settings → Pages, en Source elegir Deploy from a branch, rama main, carpeta / (root), Save.

En un par de minutos la app está en usuario.github.io/repositorio/.

Taller 3 — Probar y repartir (40 min)

• Abrir el enlace en tres navegadores distintos y en el móvil.
• Generar un código QR del enlace.
• Anotar todo lo que falle y arreglarlo con la IA (volviendo al ciclo de iteración de la sesión 2).
• Comparar las dos plataformas y decidir cuál usará cada uno de aquí en adelante.

3. Guía para el ponente

• Posible dificultad: el alumnado del curso se pierde entre las opciones de Cloudflare, que es una plataforma pensada para profesionales.
• Cómo resolverlo: hacer el recorrido completo en el proyector primero, sin que nadie toque nada, y solo después repetirlo cada uno en su equipo. Enseñar la ruta, no la interfaz.
• Alternativa si el centro bloquea Cloudflare o GitHub: cualquiera de las dos sirve como plan B de la otra. Conviene tener preparada alguna tercera opción de alojamiento estático gratuito por si las dos fallan en la red del centro.

SESIÓN 4 — De la app suelta al recurso de aula

Ficha técnica de la sesión

• Objetivo: enriquecer la app con interactividad real, aplicarle una revisión de accesibilidad, cerrar el proyecto personal y presentarlo al grupo.
• Estructura: 1 h de exposición + 2 h de taller y cierre.
• Recursos: rúbrica del proyecto final y lista de comprobación de accesibilidad, impresas.

1. Parte teórica (60 min)

A. Tipologías de apps educativas y qué pide cada una en el prompt (20 min)

B. Accesibilidad comprobable, no declarativa (20 min)

De la teoría a la comprobación práctica: tamaño mínimo de los elementos que se pulsan, contraste suficiente entre texto y fondo, funcionamiento con teclado, etiquetas en los botones que solo tienen icono, y respeto a quien ha pedido menos animaciones en su sistema. Son criterios de referencia internacional (WCAG 2.2) y se pueden pedir directamente en el prompt.

C. Del aula al centro: compartir y saber cuándo parar (20 min)

• Compartir lo que funciona con el departamento o con el claustro. Un recurso bien hecho se reutiliza durante años.
• Licencia y autoría: decidir con qué licencia se comparte.
• Cuándo una app web se queda corta: si necesitas guardar datos de alumnos, gestionar usuarios o guardar archivos en el servidor, esta arquitectura no llega. Es el momento de pasar a un proyecto con servidor —o al curso de aplicaciones de escritorio, donde todo se queda dentro del ordenador del centro.

2. Parte práctica (120 min)

Taller 1 — Interactividad avanzada (30 min)

Añadir a la app, con peticiones nuevas a la IA: puntuación acumulada, barra de progreso, guardado del resultado en el navegador, mensajes de refuerzo, reinicio de la actividad.

Taller 2 — Ronda de accesibilidad y arreglos (30 min)

Cada asistente pasa la lista de comprobación a su propia app y pide las correcciones a la IA. Se comprueba a mano: agrandar el texto del navegador, navegar solo con el tabulador, verla en el móvil.

Taller 3 — Ensamblaje del proyecto final (30 min)

Cada docente reúne lo trabajado en las cuatro sesiones: la ficha de necesidad, la app funcionando, el enlace público y las mejoras de accesibilidad. Se entrega el enlace, no un archivo.

Taller 4 — Evaluación entre pares (15 min)

Intercambio por parejas. Cada asistente abre el enlace del compañero, lo usa como si fuera alumnado y aplica la lista de comprobación. Dos sugerencias concretas de mejora.

Taller 5 — Muestra y cierre (15 min)

Tres o cuatro voluntarios proyectan su app. Puesta en común y entrega del decálogo.

3. Guía para el ponente

• Posible dificultad: perfeccionismo. Hay quien intentará dejar la app impecable en lugar de cerrar el proceso.
• Cómo resolverlo: recordar que el criterio de éxito es tener un enlace que funciona y que alguien puede usar, no tener un producto acabado. Lo que no se pula hoy se pule el trimestre que viene con la misma app abierta.
• Nota: la muestra final no da para 20 personas. Tres o cuatro voluntarios y el resto de enlaces se comparten en el espacio del curso.

ANEXOS PARA EL PONENTE

Anexo 1 — Rúbrica de evaluación del proyecto final

Anexo 2 — Lista de comprobación antes de publicar una app

1. El archivo se llama exactamente index.html.
2. Se abre correctamente con doble clic, sin servidor.
3. Funciona en Chrome, Firefox y Safari, y en el móvil.
4. Los botones son lo bastante grandes para pulsarlos en una tablet.
5. El texto se lee bien sobre el fondo (contraste suficiente).
6. Se puede usar solo con el teclado.
7. Los botones que solo llevan icono tienen etiqueta para lectores de pantalla.
8. No hay ningún cuadro de diálogo nativo del navegador que bloquee la actividad.
9. La puntuación o el progreso sí se guardan al recargar.
10. El enlace público está probado en otro dispositivo distinto del que lo creó.

Anexo 3 — Decálogo del docente que crea sus propias aplicaciones

1. Empieza por la necesidad, no por la herramienta. Si no sabes qué problema resuelve, no la hagas.
2. Describe antes de pedir. El prompt maestro ahorra horas de corrección.
3. No leas el código. Lee el resultado.
4. El error es el material de la siguiente petición. Cópialo, no lo escondas.
5. Itera sin miedo. Nadie rompe nada que no se pueda volver a pedir.
6. Un archivo, siempre. Los archivos sueltos son rutas rotas esperando a ocurrir.
7. Publica pronto. Una app que no tiene enlace no sirve a nadie.
8. Diseña para los extremos. Quien más se beneficia de la accesibilidad es quien menos lo dice.
9. Comparte lo que funciona. El departamento entero gana con tu app.
10. Los datos del alumnado, fuera de la nube. En esta arquitectura se quedan en su dispositivo: mantenlo así.

TRAZABILIDAD: QUÉ VIENE DEL ESBOZO ANTERIOR Y QUÉ ES NUEVO

El esbozo previo (Propuesta Curso IA Nivel II, 10 h) planteaba un curso con este enfoque, que se ha conservado íntegro y ampliado:

Añadido por el contexto del aula real: la lista de comprobación antes de publicar, el ejercicio de romper la app a propósito, y el aviso explícito de lo que una web estática no puede hacer (recoger datos del alumnado). Sin ese aviso, el profesorado llega a la conclusión equivocada en la tercera sesión.

Origen documental: el contenido técnico de esta propuesta se apoya en el cuaderno de NotebookLM "Curso Creacion de apps web con IA (CEP 26/27)", con 16 fuentes verificadas, entre ellas la documentación oficial de MDN, del W3C (WCAG 2.2), de Cloudflare Pages y de GitHub Pages.

PENDIENTE DE CONFIRMAR

Estos datos dependen de la convocatoria del CEP y están estimados, no verificados:

• Plazos de presentación y periodo de impartición.
• Número mínimo y máximo de asistentes.
• Si la convocatoria exige memoria final del ponente y con qué formato.
• Si las horas de trabajo autónomo computan a efectos de certificación.
• Denominación oficial del curso y codificación en la aplicación del CEP.
• Si el aula del CEP tiene acceso sin restricciones a Cloudflare y a GitHub. Conviene comprobarlo antes: si la red los bloquea, la sesión 3 necesita un plan alternativo.

Propuesta elaborada por Luis Solá Mantilla para el CEP de Cantabria · Curso 2026/2027