search

Program-AR / gs-element-blockly

Blockly element for gobstones web
GNU Lesser General Public License v3.0
1 stars 4 forks source link

Configuración Inicial del toolbox configurable por parámetro #6

Closed asanzo closed 7 years ago

asanzo commented 7 years ago

En Gobstones Web va a haber idea de "Actividades", donde se espera que los editores que se muestren sean ligeramente distintos.

En principio, entre las distintas actividades los editores sólo diferirían en que algunas categorías se mostrarán y otras no, y algunos bloques se mostrarán y otros no.

Entonces, el componente gs-element-blockly debería recibir por parámetro las categorías y/o bloques a mostrarse.

Me gustaría definir con el equipo de Gobstones Web qué interfaz esperarían que tenga el componente para lograr esto.

¿Qué queremos? ¿Que existan parámetros como "showCategories=['alternativas','repeticiones']" y/o "hideCategories" y "showBlocks" y "hideBlocks"? ¿Ú otra cosa de más alto nivel?

@faloi , ¿opiniones?

faloi commented 7 years ago

Lo que queremos con @fidel-ml son dos niveles de configuración: bloques visibles y bloques activados.

Esto no es capricho sino que responde al siguiente principio: toda herramienta que fue presentada en una actividad tiene que quedar visible en todas las siguientes, de modo que la caja de herramientas siempre se incremente. Aún así, en algunas actividades puede tener sentido no permitir el uso de ciertos bloques.

En cuanto a la granularidad, deberíamos poder hacer esta configuración a nivel bloque: oculto, visible habilitado, visible deshabilitado. Las categorías deberían aparecer solamente cuando alguno de sus bloques aparecen.

asanzo commented 7 years ago

Buenas!

Según esto, distingo tres estados posibles:

En general, tengo problemas con el "habilitado". No veo la necesidad pedagógica. Si no querés que el pibe use un bloque, no lo pongas en el toolbox y listo. ¿Qué ganás con mostrárselo grisado? Es de mala persona eso :stuck_out_tongue_closed_eyes:

Quizás cuando hablamos de codificación escrita tiene más sentido hacer esa división.

Más allá de eso, (se haga ó no se haga lo de habiliado), entiendo que la responsabilidad de decidir qué bloques nuevos se agregan en una actividad está del lado de la app Gobstones Web, y no del componente gs-element-blockly.

Entonces, pregunto:

¿Bastaría con implementar properties así?

<gs-element-blockly visibleBlocks:'[Rojo, Verde, Azul, Repetir, RepetirHasta, Sacar, Poner]'></gs-element-blockly>
faloi commented 7 years ago

Fue una discusión larga que tuvimos en el equipo, le dejo a @fidel-ml la tarea de reproducirla.

La interfase (nunca sé cómo escribir esa palabra) me parece que está bien, aunque no termino de ver por qué tiene que ser HTML. Algo que me imagino que sería interesante es tener una forma de consultar qué bloques existen y en qué categorías están, para eventualmente armar una UI que te deje seleccionar.

@rodri042, porfa opiná sobre lo que propone Alf.

afska commented 7 years ago

Sí. Para mí estaría bien así. Aunque si hacemos lo de bloques grisados deberían ser dos grupos (visibles y deshabilitados).

Sería copado que eso se pueda bindear contra una propiedad y se puedan agregar bloques visibles sin tener que recargar el elemento, perdiendo así lo que fue armando el pibe. Pero ojo, estoy volando, todavía no hablamos nada de cómo encarar las actividades

fidel-ml commented 7 years ago

La idea pedagógica es que vos le estás enseñando una serie de herramientas conceptuales, y armando un mapa mental con las mismas. Entonces, si ya conoce una herramienta, tiene que aparecer en el mapa: no tiene sentido un mapa que cambia a cada rato, pero sí uno que crece (sacando "FoW"... :)). Sin embargo, hay actividades que invitan a solucionar el problema de cierta manera, y entonces se requiere que no utilicen algunas de las herramientas (por ejemplo, si quiero forzar a que use while, le pido ir al borde, pero sin usar la primitiva... :)). Incluso, pensando más allá (de manera inconsulta), se me ocurre que si hay procedimientos dados como "primitivos" (no son primitivos pues son procedimientos, pero vienen hechos en la actividad), puedo querer que usen esos y no los comandos primitivos posta (por ejemplo, tengo PonerManzana() y SacarManzana() y no quiero que usen Poner(?) o Sacar(?), ¿se entiende?)

2016-12-01 17:48 GMT-03:00 asanzo notifications@github.com:

Buenas!

Según esto, distingo tres estados posibles:

  • Visible y habilitado: Aparece en el toolbox y se puede usar normalmente.
  • Visible y no habilitado: ¿Aparecería en el toolbox grisado y sin poderse usar?
  • No visible: No aparece en el toolbox, independientemente de estar habilitado ó no.
  • Descarto que esté no visible y habilitado, porque no se puede usar un bloque que no esté en el toolbox. Esto es un feature raro que nacía de poder importar soluciones en Pilas Bloques, cosa que en Gobstones Web, según entiendo, no va a pasar.

En general, tengo problemas con el "habilitado". No veo la necesidad pedagógica. Si no querés que el pibe use un bloque, no lo pongas en el toolbox y listo. ¿Qué ganás con mostrárselo grisado? Es de mala persona eso 😝

Quizás cuando hablamos de codificación escrita tiene más sentido hacer esa división.

Más allá de eso, (se haga ó no se haga lo de habiliado), entiendo que la responsabilidad de decidir qué bloques nuevos se agregan en una actividad está del lado de la app Gobstones Web, y no del componente gs-element-blockly.

Entonces, pregunto:

¿Bastaría con implementar properties así?

<gs-element-blockly visibleBlocks:'[Rojo, Verde, Azul, Repetir, RepetirHasta, Sacar, Poner]'>

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Program-AR/gs-element-blockly/issues/6#issuecomment-264290358, or mute the thread https://github.com/notifications/unsubscribe-auth/AIaqtjG8qyRUqpXLklwY5quqymshTmqpks5rDzKygaJpZM4K_j8U .[image: Web Bug from https://github.com/notifications/beacon/AIaqtuBfudVbc0qNQgy095vGWlEkMXlyks5rDzKygaJpZM4K_j8U.gif] {"api_version":"1.0","publisher":{"api_key":" 05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity": {"external_key":"github/Program-AR/gs-element-blockly" ,"title":"Program-AR/gs-element-blockly","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/ 143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png"," avatar_image_url":"https://cloud.githubusercontent.com/ assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png ","action":{"name":"Open in GitHub","url":"https://github. com/Program-AR/gs-element-blockly"}},"updates":{" snippets":[{"icon":"PERSON","message":"@asanzo in #6: Buenas!\r\n\r\nSegún esto, distingo tres estados posibles:\r\n\r\n- Visible y habilitado: Aparece en el toolbox y se puede usar normalmente.\r\n- Visible y no habilitado: ¿Aparecería en el toolbox grisado y sin poderse usar?\r\n- No visible: No aparece en el toolbox, independientemente de estar habilitado ó no. \r\n- Descarto que esté no visible y habilitado, porque no se puede usar un bloque que no esté en el toolbox. Esto es un feature raro que nacía de poder importar soluciones en Pilas Bloques, cosa que en Gobstones Web, según entiendo, no va a pasar.\r\n\r\nEn general, tengo problemas con el \"habilitado\". No veo la necesidad pedagógica. Si no querés que el pibe use un bloque, no lo pongas en el toolbox y listo. ¿Qué ganás con mostrárselo grisado? Es de mala persona eso :stuck_out_tongue_closed_eyes: \r\n\r\nQuizás cuando hablamos de codificación escrita tiene más sentido hacer esa división.\r\n\r\n--------------------------------------\r\n\r\nMás allá de eso, (se haga ó no se haga lo de habiliado), entiendo que la responsabilidad de decidir qué bloques nuevos se agregan en una actividad está del lado de la app Gobstones Web, y no del componente gs-element-blockly.\r\n\r\nEntonces, pregunto:\r\n\r\n¿Bastaría con implementar properties así?\r\n\r\nhtml\r\n\u003cgs-element-blockly visibleBlocks:'[Rojo, Verde, Azul, Repetir, RepetirHasta, Sacar, Poner]'\u003e\u003c/gs-element-blockly\u003e\r\n"}],"action":{"name":"View Issue","url":"https://github.com/Program-AR/gs-element- blockly/issues/6#issuecomment-264290358"}}}

Este mensaje ha sido analizado por el servidor antispam2.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

fidel-ml commented 7 years ago

La disposición en grupos de los elementos es fija, estén o no deshabilitados. O sea, el mapa tiene que ser EL MISMO a lo largo de todas las actividades, y solo se puede incrementar a medida que cada actividad es más avanzada. No sirve que se agrupen los deshabilitados en un lado separado...

Si trata de usar un comando deshabilitado, el mensaje debería ser algo como "Esta actividad tenés que solucionarla sin este elemento" o algo así.

El mapa se parecerá mucho al que vimos con Alf para PilasBloques (¿lo tenés para compartir, Alf, así no lo recreo?), con el agregado de que va a haber "procedimientos primitivos" además de "comandos primitivos" (los comandos primitivos son Poner, Sacar, Mover, IrAlBorde, VaciarTablero, mientras que los procedimientos primitivos son aquellos definidos en la biblioteca del docente, que son atómicos).

2016-12-01 18:44 GMT-03:00 Rodrigo Alfonso notifications@github.com:

Sí. Para mí estaría bien así. Aunque si hacemos lo de bloques grisados deberían ser dos grupos (visibles y deshabilitados).

Sería copado que eso se pueda bindear contra una propiedad y se puedan agregar bloques visibles sin tener que recargar el elemento, perdiendo así lo que fue armando el pibe. Pero ojo, estoy volando, todavía no hablamos nada de cómo encarar las actividades

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Program-AR/gs-element-blockly/issues/6#issuecomment-264304851, or mute the thread https://github.com/notifications/unsubscribe-auth/AIaqtsBICHLMuOWDEM5j0S2g_w6Uig7Kks5rDz-4gaJpZM4K_j8U .[image: Web Bug from https://github.com/notifications/beacon/AIaqtgkqY88Pl-_nwzkuOGcavuUXZjMfks5rDz-4gaJpZM4K_j8U.gif] {"api_version":"1.0","publisher":{"api_key":" 05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity": {"external_key":"github/Program-AR/gs-element-blockly" ,"title":"Program-AR/gs-element-blockly","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/ 143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png"," avatar_image_url":"https://cloud.githubusercontent.com/ assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png ","action":{"name":"Open in GitHub","url":"https://github. com/Program-AR/gs-element-blockly"}},"updates":{" snippets":[{"icon":"PERSON","message":"@rodri042 in #6: Sí. Para mí estaría bien así. Aunque si hacemos lo de bloques grisados deberían ser dos grupos (visibles y deshabilitados). \r\n\r\nSería copado que eso se pueda bindear contra una propiedad y se puedan agregar bloques visibles sin tener que recargar el elemento, perdiendo así lo que fue armando el pibe. Pero ojo, estoy volando, todavía no hablamos nada de cómo encarar las actividades"}],"action":{"name":"View Issue","url":"https://github. com/Program-AR/gs-element-blockly/issues/6#issuecomment-264304851"}}}

Este mensaje ha sido analizado por el servidor antispam1.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

asanzo commented 7 years ago

El mapa del que habla Fidel está acá.

Que aparezca siempre en la misma categoría ya lo habíamos implementado en Pilas Bloques, es factible. Lo detallo en #9

Desde la aplicación Gobstones Web (no desde este componente) se va a decidir qué bloques se muestran y qué bloques no, idem con estar habilitados ó no. La lista de bloques la tienen que armar ellos, por ahora. Quizás les agreguemos, como dice Fede, una forma de obtener la lista de bloques.

Sobre "Procedimientos primitivos", eso es un feature diferente. Avancemos sobre el feature presente y después vayamos a ese. Hay cosas a discutir por separado.

Respecto de estar "habilitado", cito a @fidel-ml :

Si trata de usar un comando deshabilitado, el mensaje debería ser algo como "Esta actividad tenés que solucionarla sin este elemento" o algo así.

¡Momento!

Yo me imaginaba que cuando un bloque estaba deshabilitado entonces se listaba grisado Y no se podía mover del toolbox.

¿Vos querés que se pueda usar ese bloque deshabilitado?

P.D.: Fidel, ¡por el amor de Gauss dejá de hacer tus propios saltos de línea! :laughing: Me pone frenético. :sweat_smile:

fidel-ml commented 7 years ago

No, no quiero que se pueda sacar del toolbox. Pero si se para arriba y trata de sacarlo, estaría bueno un mensaje de error que le diga por qué no puede. Si es quilombo, y el gris es como que no existe, entonces leesto.

PD: Qué es "mis propios saltos de línea"?

2016-12-02 18:56 GMT-03:00 asanzo notifications@github.com:

El mapa del que habla Fidel está acá https://github.com/Program-AR/gs-element-blockly/issues/1.

Que aparezca siempre en la misma categoría ya lo habíamos implementado en Pilas Bloques, es factible. Lo detallo en #9 https://github.com/Program-AR/gs-element-blockly/issues/9

Desde la aplicación Gobstones Web (no desde este componente) se va a decidir qué bloques se muestran y qué bloques no, idem con estar habilitados ó no. La lista de bloques la tienen que armar ellos, por ahora. Quizás les agreguemos, como dice Fede, una forma de obtener la lista de bloques.

Sobre "Procedimientos primitivos", eso es un feature diferente. Avancemos sobre el feature presente y después vayamos a ese. Hay cosas a discutir por separado.

Respecto de estar "habilitado", cito a @fidel-ml https://github.com/fidel-ml :

Si trata de usar un comando deshabilitado, el mensaje debería ser algo como "Esta actividad tenés que solucionarla sin este elemento" o algo así.

¡Momento!

Yo me imaginaba que cuando un bloque estaba deshabilitado entonces se listaba grisado Y no se podía mover del toolbox.

¿Vos querés que se pueda usar ese bloque deshabilitado?

P.D.: Fidel, ¡por el amor de Gauss dejá de hacer tus propios saltos de línea! 😆 Me pone frenético. 😅

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Program-AR/gs-element-blockly/issues/6#issuecomment-264573260, or mute the thread https://github.com/notifications/unsubscribe-auth/AIaqthj3G2K5VGIGC6IEP5RzHh7S04mgks5rEJQdgaJpZM4K_j8U .[image: Web Bug from https://github.com/notifications/beacon/AIaqtqns4hyB0H5n2EcO89mCXL7qh_cAks5rEJQdgaJpZM4K_j8U.gif] {"api_version":"1.0","publisher":{"api_key":" 05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity": {"external_key":"github/Program-AR/gs-element-blockly" ,"title":"Program-AR/gs-element-blockly","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/ 143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png"," avatar_image_url":"https://cloud.githubusercontent.com/ assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png ","action":{"name":"Open in GitHub","url":"https://github. com/Program-AR/gs-element-blockly"}},"updates":{" snippets":[{"icon":"PERSON","message":"@asanzo in #6: El mapa del que habla Fidel está acá.\r\n\r\nQue aparezca siempre en la misma categoría ya lo habíamos implementado en Pilas Bloques, es factible. Lo detallo en

9\r\n\r\nDesde la aplicación Gobstones Web (no desde este componente) se

va a decidir qué bloques se muestran y qué bloques no, idem con estar habilitados ó no. La lista de bloques la tienen que armar ellos, por ahora. Quizás les agreguemos, como dice Fede, una forma de obtener la lista de bloques.\r\n\r\nSobre \"Procedimientos primitivos\", eso es un feature diferente. Avancemos sobre el feature presente y después vayamos a ese. Hay cosas a discutir por separado.\r\n\r\nRespecto de estar \"habilitado\", cito a @fidel-ml :\r\n\u003e Si trata de usar un comando deshabilitado, el mensaje debería ser algo como \"Esta actividad tenés que solucionarla sin este elemento\" o algo así.\r\n\r\n¡Momento!\r\n\r\nYo me imaginaba que cuando un bloque estaba deshabilitado entonces se listaba grisado Y no se podía mover del toolbox.\r\n\r\n¿Vos querés que se pueda usar ese bloque deshabilitado?\r\n\r\nP.D.: Fidel, ¡por el amor de Gauss dejá de hacer tus propios saltos de línea! :laughing: Me pone frenético. :sweat_smile: \r\n"}],"action":{"name":"View Issue","url":"https://github. com/Program-AR/gs-element-blockly/issues/6#issuecomment-264573260"}}}

-- Este mensaje ha sido analizado por el servidor antispam1.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

asanzo commented 7 years ago

@miguelgarcia

Hoy hay un problema. La interfaz que figura es la siguiente:

seleccion_057

Pero en el issue #23 Figura "Entra: lista de ids de bloques visibles, y lista de ids de bloques deshabilitados."

¿Por qué es un String? Deberían ser dos listas.

Hablando con la gente de Gobstones, dijimos que un ejemplo posible es de tipo object ó JSON, con dos key/value:

{
"visible": ["Comandos primitivos", "Literales", "Expresiones"],
"disabled": ["Poner", "hayBolitas", "Literales"]
}

Notar ahí un feature adicional: puede venir un nombre de categoría, para no tener que escribir todos los bloques de esa categoría. Podemos charlar esto último, pero el object con las dos listas debe estar.