Importing media into codeworld

[Brandon Barker]

Perhaps I missed the relevant information (again). 

We've used Scratch Jr at home, and we like that a lot. But I also love cow code.world/blocks creates Haskell code from blocks. I don't imagine that Code World would have a drawing program like Scratch Jr (at least initially), and in my opinion, it is nice to be somewhat flexible at the beginning, so importation of images seems like a good starting point. Aside from storage issues, I imagine one might want to have a somewhat more rigorous way of dealing with images or pictures within the scene (e.g. a scene graph).

[Chris Smith]

You cannot import images into CodeWorld.  This is actually intentional.  While importing images is more engaging, it deters students from spending the time composing expressions when drawing.  As soon as you can search for a professional quality cartoon on Google Image Search, we're now punishing students who choose to compose their own programs, because they have little hope of competing with professional quality graphics.

Composed drawings have the advantage, for beginning students, of connecting code structures directly to things you can see in the result.  Students who skip to thinking deeply about subexpressions and decomposition for the first time when solving more abstract problems tend to just hit a wall, lacking the comprehension they would need to mix in functional or data abstraction with their skills.

So for this reason, I'm reluctant to include images.  It's probably best to use a different tool for that.

Feel free to make the opposite case; but I wanted to explain the disadvantages of image imports.

On Sun, Sep 2, 2018, 1:03 PM Brandon Barker <brandon...@gmail.com> wrote:

Perhaps I missed the relevant information (again). 

We've used Scratch Jr at home, and we like that a lot. But I also love cow code.world/blocks creates Haskell code from blocks. I don't imagine that Code World would have a drawing program like Scratch Jr (at least initially), and in my opinion, it is nice to be somewhat flexible at the beginning, so importation of images seems like a good starting point. Aside from storage issues, I imagine one might want to have a somewhat more rigorous way of dealing with images or pictures within the scene (e.g. a scene graph).

--
You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-disc...@googlegroups.com.
To post to this group, send email to codeworl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/7f191692-bde8-4eff-9de7-f1ba041a0a8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brandon Barker]

I think that's a compelling point, and I hadn't really thought of the negative impact of adding the feature. 

Another possibility would be something like Scratch Jr (I know, I just advocated for NOT doing things exactly like scratch), which instead of doing image import, actually contains a collection of generated art that students could use. This would make sure all students were on an equal playing field, but they might still suffer from the other point you mentioned about abstract reasoning if they skip ahead without prior understanding. If this is a concern, it could perhaps be mitigated by making this public collection a set of functions that generate PIctures mathematically (but then, we're back to the obvious tradeoffs in image quality). This is more like the real world case of being given someone else's code you have to wade through and sometimes understand by breaking it or making slight changes before you get it to do what you want. But for early learners, I admit that the argument that students will ultimately be better off if they have a solid grounding in the basics is more compelling; I'm not convinced of any of my suggestions yet either; for now, we're happy to keeping going with the suggestion to generate all of our art using Haskell.

[Chris Smith]

Yep, thanks for the thoughts.

I could see a place for a small collection of built-in graphics (sprites, I guess), if (a) they were styled in a distinctive way so that it's obvious a student is using the built-in picture, and (b) they were pretty general-purpose and tried not to encourage specific creative choices.

I'm thinking of a problem that happens around midway through a year at the middle school level.  We've finished working on composing pictures, and are more focused on the logic behind movement, cause and effect, and state.  But students end up spending a disproportionate amount of their time on drawings.  Some students cope with this by extensively reusing the pictures they've made in the past.  But this puts students who overachieved early in the class at an unfair disadvantage later in the class, because they simply have more artistic work to choose from and incorporate into their later projects.  If they want a tree, a cloud, or a car, chances are they've already got one laying around in a project they made.  It's a brief copy-and-paste before they are up and running and working on the new content.  But a weaker student who just slipped by has more work to do before they are ready to begin the interesting bits.

I could see commissioning an artist to produce a canonical set of maybe 50 common pictures, in a consistent and distinctive style, that could be imported.  I would use them in the later part of the class, and specifically avoid them at the beginning.  And I could make a specific rule in my classes against using these sprites.  I'm intrigued by this idea, but not quite sure what I think yet.

To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/b82015c6-65d6-4d72-ad85-5d55ebb65b36%40googlegroups.com.

[Chris Smith]

(Obviously, I meant make a specific rule against using them for the portion of the class where we are concerned with drawings.  The whole point would be to allow them later on, when drawings are no longer the main concern.)