Saber Básico A.5: Pantallas de interacción con el usuario 2ESO

Computación y Robótica – 2º ESO

1. Recordatorio: de generar bucles y condiciones a construir una interfaz real

En el A.4 aprendiste a generar bucles y condicionales, y a usar variables para guardar datos que cambian (una cuenta atrás, una temperatura). Hoy esas dos piezas —variables y condicionales— se juntan para construir algo que existe en cualquier app real: pantallas distintas por las que el usuario se mueve, y datos que el usuario introduce y que el programa guarda y usa.

Una app de verdad no es una sola pantalla con todo mezclado. Tiene una pantalla de inicio, quizás un formulario, un resultado… y el usuario va pasando de una a otra. Hoy vamos a diseñar y construir eso.

🖥️ 2. ¿Qué es una pantalla de interacción?

Una pantalla es lo que ve el usuario en un momento concreto del programa: qué información se muestra y qué puede hacer desde ahí (qué botones pulsar, qué datos introducir).

En Scratch no hay “pantallas” como tal, pero tenemos una herramienta que cumple esa función: los fondos (backdrops). Cambiar de fondo es, en la práctica, cambiar de pantalla:

Concepto de app real	Equivalente en Scratch
Pantalla de inicio	Fondo 1
Formulario	Fondo 2
Pantalla de resultado	Fondo 3
“Ir a la siguiente pantalla”	cambiar fondo a [fondo2]

Idea clave: una pantalla no es solo una imagen de fondo distinta. Es una combinación de fondo + qué sprites se ven + qué datos se piden en ese momento.

📡 3. Elementos para pasar de una pantalla a otra: los mensajes

El botón “Empezar”, “Enviar” o “Siguiente” de cualquier app dispara un cambio de pantalla. En Scratch, ese mecanismo son los mensajes:

• enviar mensaje [nombre]: avisa a todo el proyecto de que ha pasado algo.
• al recibir mensaje [nombre]: es un bloque de evento (con forma de sombrero, como viste en el A.2) que reacciona cuando llega ese aviso.

[Sprite botón "Empezar"]
al hacer clic sobre este personaje
   enviar mensaje [ir_a_formulario]

[Fondo / script de escenario]
al recibir mensaje [ir_a_formulario]
   cambiar fondo a [pantalla_formulario]

Fíjate en algo importante: quien envía el mensaje y quien lo recibe pueden ser sprites distintos, y ni siquiera necesitan “conocerse”. El mensaje es el puente entre ellos.

Error típico: enviar un mensaje que nadie recibe (te olvidas de poner el al recibir en algún sprite), o poner nombres de mensaje distintos por una letra (ir_formulario vs ir_a_formulario). Scratch no avisa: el mensaje simplemente no llega a ningún sitio.

📋 4. Elementos para recoger datos del usuario: preguntar y guardar

Ya usaste variables en A.4 para guardar datos que el programa calculaba. Hoy vas a guardar datos que el usuario escribe:

preguntar [¿Cómo te llamas?] y esperar
fijar [nombre] a (respuesta)

El bloque preguntar... y esperar muestra un cuadro de texto y pausa el programa hasta que el usuario escribe algo y pulsa Intro. Lo que escribe se guarda automáticamente en un reportero especial llamado respuesta. Si quieres conservarlo con un nombre propio (para usarlo más adelante, en otra pantalla), tienes que copiarlo a tu propia variable, como en el ejemplo.

Y como todo dato que viene del usuario puede venir mal o vacío, hay que validarlo con un condicional, igual que en A.4:

si <(nombre) = []> entonces
   decir [Tienes que escribir algo] por (2) segundos
si no
   enviar mensaje [ir_a_siguiente_pantalla]

🧩 5. Diseñar antes de construir: el mapa de pantallas

Antes de encajar un solo bloque, hay que decidir qué pantallas hay y qué las conecta. Esto se llama un mapa (o diagrama) de pantallas:

Pantalla	¿Qué se ve / qué se pide?	¿Qué la lleva a la siguiente?
Inicio	Título y botón “Empezar”	Clic en el botón → mensaje ir_a_formulario
Formulario	Pregunta el nombre	Respuesta válida → mensaje ir_a_resultado
Resultado	Saluda usando la variable nombre	— (fin)

Idea clave: el mapa de pantallas es a una interfaz lo que la tabla de “qué se repite, qué se decide” era a un bucle en A.4: si lo diseñas antes en papel, construirlo en Scratch es casi mecánico.

📊 6. De bloques a texto: la misma idea, otra forma

Bloque	Equivalente en Python
cambiar fondo a [pantalla2]	pantalla_actual = "pantalla2"
enviar mensaje [ir_a_formulario]	Llamar a una función: mostrar_formulario()
preguntar [...] y esperar	input("...")
fijar [nombre] a (respuesta)	nombre = input("¿Cómo te llamas?")
si <(nombre) = []> entonces	if nombre == "":

En Python no existen “pantallas” ni “mensajes” como bloques especiales: una pantalla es simplemente qué código se ejecuta en cada momento, y pasar de una a otra es llamar a la función siguiente. La idea de fondo es la misma que en Scratch, solo cambia cómo se escribe.

📝 PARA TU LIBRETA (Resumen clave para copiar)

Copia en tu cuaderno este resumen de 5 puntos:

1. Una pantalla es una combinación de fondo + sprites visibles + datos que se piden en ese momento.
2. Los mensajes (enviar / al recibir) son el mecanismo para pasar de una pantalla a otra: quien envía y quien recibe pueden ser sprites distintos.
3. preguntar... y esperar pausa el programa y guarda la respuesta del usuario en el reportero respuesta; hay que copiarla a tu propia variable si la quieres conservar.
4. Todo dato del usuario se valida con un condicional antes de dejarle avanzar de pantalla.
5. Antes de construir, se diseña el mapa de pantallas: qué hay en cada una y qué evento lleva a la siguiente.

---

FICHA DE TRABAJO DESENCHUFADA: DISEÑO DE PANTALLAS DE INTERACCIÓN

Saber Básico A.5: Pantallas de interacción con el usuario

Nombre y Apellidos: ____________________________________________________

Curso y Grupo: 2.º ESO ____ | Fecha: __ /__ /2026

---

🔍 RETO 1: Detective de pantallas

Lee esta descripción de una app y responde a las preguntas:

“Una app de registro para el equipo de BermejaSat. Al abrirla, se ve el logo y un botón ‘Registrarme’. Al pulsarlo, pide el nombre del alumno y su curso. Si deja algún campo vacío, avisa de que faltan datos y no avanza. Si está todo relleno, muestra una pantalla final con ‘Bienvenido, [nombre], de [curso]’.”

Pregunta	Respuesta
¿Cuántas pantallas distintas hay como mínimo?
¿Qué variables necesita guardar el programa?
¿Qué evento lleva de la pantalla 1 a la pantalla 2?
¿Dónde hace falta un condicional, y para qué comprueba?
¿Qué mensaje(s) necesitarías enviar, y quién los recibiría?

Reflexión: si el programa no validara los campos vacíos, ¿qué podría pasar en la pantalla final?
Respuesta: ____________________________________________________________________

---

🗺️ RETO 2: Diseña el mapa

Vas a diseñar (no a programar) las pantallas de esta app:

“Un cuestionario rápido para saber si un alumno puede subir a la próxima excursión de AIDARAC a la Sierra Bermeja. Pantalla de inicio con un botón. Pregunta si trae calzado adecuado (sí/no). Si contesta que no, muestra un mensaje de que no puede subir y termina ahí. Si contesta que sí, pregunta su nombre y muestra una pantalla final de confirmación con su nombre.”

Dibuja el mapa de pantallas (cajas conectadas con flechas) en el reverso o en tu cuaderno, y después rellena esta tabla:

Pantalla	¿Qué se ve / qué se pide?	¿Qué la lleva a la siguiente?

Reflexión: esta app tiene un camino que no llega a la pantalla final. ¿Cuál es, y por qué el diseño necesita ese camino “corto”?
Respuesta: ____________________________________________________________________

---

🐞 RETO 3: Cazador de errores

Estos dos fragmentos tienen fallos que impiden que la interfaz funcione bien, aunque se puedan montar sin error de encaje. Para cada uno, explica qué falla y cómo lo arreglarías.

Fragmento A (el botón “Empezar” debería llevar a la pantalla del formulario)

[Sprite botón]
al hacer clic sobre este personaje
   enviar mensaje [comenzar]

[Fondo]
al recibir mensaje [empezar]
   cambiar fondo a [formulario]

Fragmento B (debería guardar el nombre del usuario para usarlo después)

al recibir mensaje [ir_a_formulario]
preguntar [¿Cómo te llamas?] y esperar
cambiar fondo a [pantalla_final]
decir (unir [Bienvenido, ] (nombre))

Fragmento	¿Qué falla?	¿Cómo lo arreglo?
A
B

Conclusión del Reto 3: en ambos casos Scratch deja montar el programa sin avisar de ningún error. ¿Por qué crees que estos fallos son más difíciles de detectar que un error de sintaxis en Python?
Respuesta: ____________________________________________________________________

---

💡 Dinámica sugerida para el aula (35-40 min)

• 10 min: Repaso oral de mensajes y preguntar... y esperar (pizarra, sin apuntes), con un ejemplo dibujado en la pizarra.
• 20 min: Trabajo individual o en parejas con los tres retos. El Reto 2 puede hacerse en papel cuadriculado o folio en blanco para el dibujo del mapa.
• 5-10 min: Corrección conjunta del Reto 2, comparando mapas distintos y viendo si todos representan bien el camino “corto” de la reflexión.

---

Solucionario (solo para ti)

• Reto 1: 3 pantallas (inicio, formulario, resultado). Variables: nombre, curso. Evento: clic en “Registrarme” → mensaje. Condicional: comprobar si nombre o curso están vacíos, antes de cambiar a la pantalla final. Mensajes: por ejemplo ir_a_formulario (del botón al fondo) e ir_a_resultado (del formulario, tras validar, al fondo). Si no valida: la pantalla final mostraría “Bienvenido, , de ” con los huecos vacíos.
• Reto 2: Pantallas: inicio → pregunta calzado → (si no) pantalla de aviso [fin] / (si sí) pregunta nombre → pantalla de confirmación. El camino corto es el de “calzado = no”, que no debe llegar nunca a pedir el nombre ni a la confirmación: hace falta un condicional justo después de la pregunta del calzado que decida entre los dos caminos.
• Reto 3: A) el mensaje enviado es comenzar pero el recibido es empezar: nombres distintos, el mensaje nunca llega. Solución: usar el mismo nombre en los dos bloques. B) la respuesta del usuario nunca se copia a una variable propia (nombre); al cambiar de fondo, el reportero respuesta puede no seguir mostrando el mismo valor, o simplemente no se ha guardado con un nombre que tenga sentido cuando se usa más adelante. Solución: añadir fijar [nombre] a (respuesta) justo después de preguntar... y esperar.