Create Message Feed

[asanzo]

Elaborado por @PalumboN como paso previo a la internacionalización #365

Es para lograr algo similar a esto: https://studio.code.org/s/express-2017/stage/18/puzzle/6

• Para el manejo de errores, el burbujeo de eventos ya está resuelto! :D Así que solamente habría que:

  • [ ] Handlear el ErrorDeActividad desde la aplicación.
  • [ ] Que los autómatas no informen el error. Que solamente hagan la animación indicada.

• Para manejar los diálogos, antes hay que conectar los eventos que van de la escena a la aplicación. Esto sería de manera análoga a cómo está resuelto para los errores, a grandes rasgos:

  • [ ] Cambiar el comportamiento Decir para que además de meter un actor en escena que haga un parent.postMessage como el error handler. Estos eventos se conectan a la app web mediante el servicio pilas de ember.
  • [ ] Ese evento debería poder ser escuchado desde la aplicación al igual que con los errores. Y ser handleados como se espera.

[asanzo]

@PalumboN

Consideraciones pedagógicas / de UX del Message Feed

• En el caso de los errores, me parece bien, se informaría en el diálogo principal. Me da lástima porque me parece más natural que hable el personajito. Es mi principal queja, si se va a entender o no. Por ejemplo ¿Se entiende que "acá" es esa casilla si no está ese globo ahí?

• En lugares como No me canso de saltar o El Superviaje aparecerían varios mensajes en una cola larga. Creo que no es problema, aunque el enunciado quedaría re arriba en el Message Feed.

• Notar que el informe de error se hace con un comportamiento Decir, que tiene un feature de nunca eliminar el globo. Entiendo que esto a priori no sería un problema, porque sería el comportamiento deseado del message feed (que quede el bichito animado triste y el último mensaje de error visible en el Feed).

Consideraciones técnicas

Podemos olvidarnos de los errores

Handlear el ErrorDeActividad desde la aplicación.

Si entiendo bien, ese catch de ErrorDeActividad nunca entra al if, hay que sacarlo de ahí, está mal. ¿Por qué? Porque el interpreter.step() y el interpreter.run() lo único que hacen es encolar comportamientos con hacer_luego. Dentro del hacer_luego, como se ve acá, sólo se hace un new del comportamiento, y por lo que vi en exercises no hay demasiado código en los constructores de los comportamientos y creo que ninguno tira un ActividadError, así que nunca entra al if. El verdadero lugar por donde sí aparecen los errores es donde vos decís en el tercer punto.

Si queremos diferenciar en Pilas Bloques una ejecución terminada con error de una ejecución terminada sin error, deberíamos colgarnos de esa. Pero yo opino que, como hoy no estamos haciendo esa diferencia, podemos no hacer este primer punto que sugerís.

De hecho, si nos colgamos del "Decir", técnicamente tampoco necesitamos el segundo punto que mencionás:

Que los autómatas no informen el error. Que solamente hagan la animación indicada.

Así que también podría volar. En Pilas Bloques hoy un informe de error de actividad o un "decir" son lo mismo, así que podemos sólo hacer la parte de "manejar los diálogos"

Problemas posibles

• Cuando no habla el autómata, como en El detective Chaparro:
• Notar también que el .decir(...) crea inmediatamente un globo, mientras que el comportamiento Decir encola la aparición del globo y tiene una duración. Esta duración se usa sólo en El detective Chaparro, por lo que estoy viendo.

Consideración Final

Entonces estamos diciendo no nos interesa nunca más mostrar un globo de decir o de pensar en Pilas Bloques ¿verdad? Creo que cambiaría los "decir" por "inform" y deprecaría el uso de "decir" que está tradicionalmente asociado al globo.

[asanzo]

Estoy muy tentado a NO hacer este feed. A medida que pasa el tiempo me parece que los globos son superadores. Esto lo tenemos que charlar con la gente de didáctica/contenidos. FerC, TomiC, Juli, Marquitos, Male. No me parece un cambio menor.

[rgonzalezt]

No lo vamos a hacer.