A lo largo de los años, el equipo de Blockly y Blockly Games ha aprendido muchas lecciones que se pueden aplicar a los que están desarrollando nuevos bloques. Los siguientes son un una colección de errores que cometimos o errores que suelen cometer otros.
Estas son lecciones generales que aprendimos usando el estilo visual de Blockly y podrían no aplicarse a todos los casos de uso o diseños. Existen otras soluciones. Este es Tampoco es una lista exhaustiva de los problemas que los usuarios pueden encontrar y cómo evitar de ellos. Cada caso es un poco diferente y tiene sus ventajas y desventajas.
1. Condicionales frente a bucles
Los bloques más difíciles para los usuarios nuevos son los condicionales y bucles. Muchos los entornos basados en bloques agrupan ambos bloques en los mismos “Controles” categoría, y ambos bloques tienen la misma forma y el mismo color. Esto suele llevar a la frustración, ya que los nuevos usuarios confunden los dos bloques. Blockly recomienda mover condicionales y bucles a una "Logic" separada y Bucles categorías, cada una con un color diferente. Esto deja en claro que estas son ideas distintas que se comportan de manera diferente, a pesar de tener formas similares.
Recomendación: Mantén los condicionales y bucles separados.
2. Listas basadas en uno
Los programadores principiantes reaccionan mal cuando se encuentran con listas basadas en cero durante tiempo. Como resultado, Blockly hace listas para seguir el ejemplo de Lua y Lambda Moo. y la indexación de cadenas basada en uno.
Para usos más avanzados de Blockly, se admiten listas basadas en cero para hacer la transición al texto sea más fácil. Para públicos más jóvenes o principiantes de todos modos se recomienda la indexación basada en uno.
Recomendación: Uno es el primer número.
3. Entradas del usuario
Existen tres maneras de obtener un parámetro del usuario. Un menú desplegable es más restrictivo y es bueno para instructivos y ejercicios sencillos. Un campo de entrada permite una mayor libertad y es bueno para actividades más creativas. Un bloque de valor de entrada (generalmente con un bloque paralelo) ofrece la oportunidad de calcular un valor (p.ej., un generador aleatorio) en lugar de ser solo un valor estático.
Recomendación: Elige un método de entrada adecuado para tus usuarios.
4. Imágenes de bloqueo en vivo
La documentación de los bloques debe incluir imágenes de los bloques a los que hace referencia. a los que tiene acceso una cuenta. Tomar capturas de pantalla es fácil. Pero si hay 50 de esas imágenes y la una aplicación web está traducida a 50 idiomas y, de repente, uno mantiene 2,500. imágenes estáticas. Luego, cambia el esquema de colores y es necesario actualizar 2500 imágenes. ... de nuevo.
Para liberarnos de esta pesadilla del mantenimiento, Blockly Games reemplazó Todas las capturas de pantalla con instancias de Blockly ejecutándose en modo de solo lectura. El resultado sea idéntico a una imagen, pero se garantiza que está actualizada. Solo lectura hizo posible la internacionalización.
Recomendación: Si admites más de un idioma, usa el modo de solo lectura.
5. Tu otra izquierda
Comentarios de niños en EE.UU. (aunque no de otros países) reveló una confusión generalizada entre izquierda y derecha. Esto se resolvió con el suma de flechas. Si la dirección es relativa (con un avatar, por ejemplo) el el estilo de flecha es importante. A → la flecha recta o la ↱ girar son confusas cuando el avatar está orientado en la dirección opuesta. El más útil es un círculo ⟳ incluso en los casos en que el ángulo inclinado es menor que lo que indica la flecha.
Recomendación: Complementa el texto con íconos Unicode cuando sea posible.
6. Bloques de alto nivel
Siempre que sea posible, se debe adoptar un enfoque de nivel más alto, aun si se reduce la flexibilidad o el rendimiento de la ejecución. Considera esta expresión de Apps Script:
SpreadsheetApp.getActiveSheet().getDataRange().getValues()
En una asignación 1:1 que preserva todas las capacidades posibles, las que se mencionaron anteriormente se crearía con cuatro bloques. Pero Blockly apunta a un nivel más alto y proporcionará un bloque que encapsule la expresión completa. El objetivo es para optimizar el caso del 95%, incluso si hace que el 5% restante sea más difícil. Blockly no tiene como objetivo sustituir a los idiomas basados en texto, destinada a ayudar a los usuarios a superar la curva de aprendizaje inicial para que puedan usar lenguajes basados en texto.
Recomendación: No conviertas toda tu API en bloques a ciegas.
7. Valores de retorno opcionales
En la programación basada en texto, muchas funciones realizan una acción y, luego,
un valor. Se puede usar o no el valor que se muestra. Un ejemplo es el flujo de una pila
función pop(). Se puede llamar al pop para obtener y quitar el último elemento,
o se lo podría llamar para quitar el último elemento con el valor que se muestra
ignorando.
var last = stack.pop(); // Get and remove last element. stack.pop(); // Just remove last element.
Por lo general, los idiomas basados en bloques no son buenos para ignorar un valor que se muestra. R debe conectarse a algo que acepte el valor. Existen varias estrategias para lidiar con este problema.
a) Aborda el problema. La mayoría de los lenguajes basados en bloques diseñan el lenguaje para evitar estos casos. Por ejemplo, Scratch no tiene ningún bloque que tenga los efectos secundarios y un valor que se devuelve.
b) Proporciona dos bloques. Si el espacio en la caja de herramientas no es un problema, una simple es proporcionar dos de cada tipo de bloque, uno con sin un valor de retorno. La desventaja es que esto puede generar un error con muchos bloques casi idénticos.
c) Mutar un bloque. Usa un menú desplegable, una casilla de verificación o algún otro control que permita que el usuario elija si se muestra un valor o no. El bloque luego cambia de forma según las opciones. Un ejemplo de esto puede ser en el bloque de acceso a la lista de Blockly.
d) Coma el valor. La primera versión de App Inventor creó un canal especial que comió cualquier valor conectado. Los usuarios no comprendían el concepto y la segunda versión de App Inventor quitó el bloque de canalización y, en su lugar, Se recomendó que los usuarios solo asignaran el valor a una variable desechable.
Recomendación: Cada estrategia tiene ventajas y desventajas; elige la opción adecuada para tus usuarios.
8. Bloques en aumento
Ciertos bloques pueden requerir un número variable de entradas. Los ejemplos son un bloque de suma que suma un conjunto arbitrario de números, o una instrucción if/elseif/else bloque con un conjunto arbitrario de cláusulas elseif o un constructor de lista con una cantidad arbitraria de elementos inicializados. Hay varias estrategias, cada uno con sus ventajas y desventajas.
a) El enfoque más simple es hacer que el usuario componga el bloque de elementos más bloques. Un ejemplo sería sumar tres números anidando dos números bloques de suma. Otro ejemplo sería solo proporcionar bloques "if/else" y hacer que el usuario los anide para crear condiciones elseif.
La ventaja de este enfoque es su simplicidad inicial (tanto para el usuario como el desarrollador. La desventaja es que, en los casos en que hay una gran cantidad de anidadas, el código se vuelve muy engorroso y difícil para el usuario leer y mantener.
b) Una alternativa es expandir el bloque dinámicamente para que siempre haya uno una entrada libre al final. Del mismo modo, el bloque borra la última entrada si hay dos entradas libres al final. Este es el enfoque que la primera versión Se usa App Inventor.
Los usuarios de App Inventor no les gustó a los usuarios de App Inventor en un par de bloques que crecían automáticamente. de razones. Primero, siempre había entradas libres y el programa nunca se "complete". Segundo, insertar un elemento en el medio de la pila frustrante, ya que implicaba desconectar todos los elementos debajo de la edición y y reconectarlos. Dicho esto, si el orden no es importante y los usuarios pueden cómoda con agujeros en su programa, esta es una opción muy conveniente.
c) Para resolver el problema del agujero, algunos desarrolladores agregan botones +/- a los bloques que agregar o quitar entradas de forma manual. Abrir Roberta usa dos de esos botones para agregar o quitar entradas de la parte inferior. Otros desarrolladores agregan dos botones en cada uno para que la inserción y la eliminación del medio de la pila puedan acomodarse. Otros agregan dos botones arriba/abajo en cada fila para que el orden de la pila puede alojarse.
Esta estrategia es un espectro de opciones que va desde solo dos botones por bloque, hasta cuatro botones por fila. En un extremo, está el peligro de que los usuarios no puedan para realizar las acciones que necesitan, en el otro extremo, la IU está tan llena botones que parece el puente de la nave espacial Enterprise.
d) El enfoque más flexible es agregar una burbuja mutadora al bloque. Esta se representa como un solo botón que abre un diálogo de configuración para ese bloque. Los elementos se pueden agregar, borrar o reorganizar cuando lo deseen.
La desventaja de este enfoque es que los mutadores no son intuitivos para usuarios principiantes. Para introducir mutadores se necesita algún tipo de instrucción. Las aplicaciones basadas en bloques dirigidas a niños pequeños no deben usar mutadores. Si bien, una vez aprendidos, son invaluables para los power users.
Recomendación: Cada estrategia tiene ventajas y desventajas; elige la opción adecuada para tus usuarios.
9. Generación de código limpio
Los usuarios de Advanced Blockly deberían poder ver el código generado (JavaScript, Python, PHP, Lua, Dart, etc.) y reconocer de inmediato el programa que escribieron. Esto significa que se debe hacer un esfuerzo adicional para conservar el código generado por sean legibles. paréntesis superfluos, variables numéricas, espacios en blanco triturados y las plantillas de código detallado impiden que se produzca un código elegante. El código generado debe incluir comentarios y debe cumplir con Guías de estilo de Google
Recomendación: Enorgullécete de tu código generado. Muéstraselo al usuario.
10. Dependencia del lenguaje
Un efecto secundario del deseo de obtener código limpio es que el comportamiento de Blockly se define en gran medida en términos de cómo se comporta el lenguaje compilado de forma cruzada. El más el lenguaje de salida común es JavaScript, pero si Blockly se compilara de forma cruzada a un idioma diferente, no se deben realizar intentos injustificados para preservar el el comportamiento exacto en ambos idiomas. Por ejemplo, en JavaScript, se puede usar cadena es false, mientras que en Lua es verdadero. Definir un patrón único de para que el código de Blockly se ejecute independientemente del idioma de destino pueden dar como resultado un código inmantenible que parece salido del compilador de GWT.
Recomendación: Blockly no es un idioma. Permite que el existente afectan el comportamiento.