Una aplicación combina una interfaz y unas reglas para realizar una tarea. La interfaz reúne lo que la persona ve y utiliza: controles, textos y mensajes. Antes de elegir botones necesitamos describir una necesidad. Preparar materiales sin olvidar uno es una tarea; tener muchas pantallas es una decisión de diseño que todavía no explica utilidad. Podemos representar el uso mediante tres momentos: abrir y comprender, actuar y revisar el resultado. Ese recorrido ayuda a elegir componentes y retirar elementos que no aportan una función.

Un requisito indica un comportamiento que podamos comprobar. «Mostrar cuántos materiales faltan» permite preparar casos; «ser bonita» no determina qué respuesta esperamos. Los mensajes deben explicar tanto qué hacer como qué acaba de ocurrir. Un cambio de color puede apoyar un texto, pero no debería ser la única señal. Letra legible, etiquetas concretas y navegación clara favorecen a personas distintas desde el primer boceto. Investigar una necesidad no exige recopilar nombres ni hábitos personales: una conversación sobre una tarea ficticia de aula aporta suficiente contexto para este proyecto.

En el Diseñador de App Inventor colocamos componentes y ajustamos propiedades como texto, tamaño y disposición. En Bloques programamos sus respuestas. Una propiedad describe un aspecto o estado del componente; un evento indica un hecho que puede iniciar instrucciones. El evento Click de un botón ocurre al pulsarlo. Una etiqueta muestra información y una casilla CheckBox mantiene un estado marcado o desmarcado. Los componentes tienen funciones diferentes aunque ocupen espacios parecidos en la pantalla. Cambiar el texto inicial de una etiqueta no programa por sí solo una respuesta a un botón.

Los nombres internos, como BotonAyuda o EtiquetaResultado, permiten reconocer piezas al leer bloques. Los textos visibles se escriben para la persona usuaria y no necesitan coincidir con esos nombres. Mantener esta distinción evita mostrar instrucciones técnicas innecesarias. Al responder a un evento, el programa puede modificar una propiedad de otro componente. Esa relación conecta acción y resultado. Construir una pantalla pequeña y probar un evento permite investigar cada parte antes de añadir recuento y navegación. El emulador o dispositivo del centro muestra la ejecución; el diseñador solo representa la preparación de la interfaz.

El estado de una aplicación describe su situación actual. En una lista de materiales, las casillas indican cuáles están preparados y una variable puede conservar el resultado de un recuento durante la ejecución. La pulsación de Comprobar inicia una acción, pero no representa un material nuevo. Si las casillas siguen iguales, comprobar otra vez debe describir la misma situación. Contar pulsaciones conserva una historia de acciones; contar casillas marcadas responde a una pregunta sobre el presente. Esa diferencia determina qué dato necesitamos calcular.

Para obtener el recuento actual podemos comenzar desde cero en cada comprobación y revisar qué casillas están marcadas. Así el resultado depende de los materiales representados en ese momento y no de cuántas veces se pulsó el botón. Los pendientes se relacionan con el total de elementos y con los preparados. Una condición distingue si no falta nada o si queda algo pendiente. Desmarcar también cambia el estado: admitir esa rectificación permite que la respuesta siga siendo coherente cuando la persona revisa su selección.

La lista y el cálculo forman un conjunto. Añadir un material afecta a los componentes, al recuento, a la condición de completo, a las instrucciones y a las pruebas. Revisar esas relaciones evita que la pantalla prometa una función que los bloques aún no representan. Esta coherencia se estudia durante el uso de la app. Una variable en memoria no garantiza conservar datos después de cerrarla; el almacenamiento permanente sería otra función que necesitaría decisiones y pruebas propias.

Una vista organiza una zona de la interfaz para una finalidad concreta. Inicio puede reunir la lista y el resultado, mientras Ayuda explica cómo utilizarlos. En la ruta inicial ambas se construyen con dos disposiciones verticales dentro de Screen1. Cada disposición agrupa componentes y tiene una propiedad Visible que indica si se muestra. Cambiar de vista modifica la presentación de esa misma pantalla; permite concentrar la atención en la tarea o en su explicación sin mezclar todos los elementos a la vez.

La navegación relaciona una acción con dos cambios coordinados: ir a Ayuda muestra ese grupo y oculta Inicio; Volver realiza lo contrario. Ocultar una zona sin mostrar la otra puede dejar una pantalla aparentemente vacía. Mostrar ambas puede dificultar reconocer dónde estamos y qué corresponde hacer. Por eso el regreso debe ser fácil de encontrar, y la ayuda debe explicar la tarea, los mensajes y el límite del dato simulado. Su utilidad depende de que la persona pueda continuar después de consultarla.

Aunque una vista quede oculta, los componentes y variables siguen perteneciendo a la misma ejecución. Una casilla puede continuar marcada al regresar porque no se ha creado un componente nuevo. Esa conservación durante el uso explica lo observado, pero no demuestra que los datos sobrevivan al cierre completo: ocultar no guarda en almacenamiento permanente. Dibujar los recorridos y probar la ida y la vuelta permite comprobar navegación y estado. Encontrar un camino sin salida es un fallo de funcionamiento, igual que obtener un recuento incorrecto.

Un sistema conectado puede llevar información desde un sensor y una placa hasta una aplicación mediante comunicación. Esa cadena necesita obtener, enviar, recibir e interpretar el dato. En este proyecto representamos una parte mediante simulación: un botón cambia una variable y la interfaz muestra el resultado. La cifra no procede de una placa ni de una conexión física. Debe aparecer junto a la indicación DATO SIMULADO. Un dibujo de sensor o un botón llamado Conectar no demuestra que exista comunicación con un dispositivo.

La simulación permite preparar casos conocidos para probar mensajes y condiciones antes de resolver la conexión. Los valores didácticos 20 y 80 representan dos entradas de ensayo sin unidad física atribuida. Si la interfaz usa un umbral, debemos poder explicar qué respuesta corresponde a cada caso y qué ocurriría en el límite. Sustituir después el origen simulado por uno real requeriría revisar comunicación, formato y respuesta cuando no llegue información. No presentaríamos un dato antiguo como una lectura nueva. Dibujar la cadena completa ayuda a distinguir lo construido de lo que solamente hemos representado.

Una prueba funcional comprueba una regla: recuento, rectificación, navegación o cambio de dato simulado. Una prueba de uso observa si otra persona comprende cómo completar una tarea. Quien construye la app ya conoce dónde están los controles, por lo que su facilidad de uso no representa a todo el público. Ofrece el emulador o dispositivo preparado a otra pareja y plantea una tarea sin señalar botones. Registra dónde duda, qué mensaje interpreta y si encuentra regreso. La observación debe describir el diseño, sin culpar a quien prueba.

Relaciona la mejora con el problema observado. Una etiqueta más concreta puede ayudar a comprender; recalcular evita acumulaciones; recolocar Volver facilita navegación. Después repite la tarea y comprueba también otra función para detectar efectos no deseados. Conserva el proyecto fuente .aia mediante exportación e importación en App Inventor. Una captura muestra un estado, mientras .aia permite continuar con componentes y bloques; no es lo mismo que una aplicación compilada para instalar. A01 incorpora el diseño y una microapp ejecutada; A02 reúne producto, pruebas y mejora. Ambas conservan fuentes, permisos, datos mínimos y explicación individual.