SNAP on Android

[jcaldw737]

My first question is whether this is an appropriate forum for my second question. :)

I am wondering if anyone has any tips for running SNAP through Chrome on an Android phone - in my case an SG6. Or actually any way at all on an SG6 or such.

I have difficulty in dragging blocks around and inputting numbers like, say, the input to a move block.

Thanks, in advance, for any ideas!

[brianharvey]

Actually you'll reach a wider audience if you use the Scratch forum:

https://scratch.mit.edu/discuss/topic/4455/unread

but it's okay to ask here. I've done some Snap! programming on tablets, but not on a phone, not even a "plus"-sized phone. Phones are great, though, for showing off completed projects; you share the project from your computer and put a desktop shortcut to it from the phone's browser.

If you really want to program on your phone, look into Pocket Code:

https://www.catrobat.org/intro/

[jcaldw737]

Thank you very much for the info! I didn't know we could discuss SNAP in the Scratch forum. Also I appreciate hearing about Pocket Code - that could be very helpful in the future. There was no way to tell from my post, but my immediate need is for more devices to run SNAP. I have some K-12 educators coming to a "Computer Coding in Elementary Schools" workshop where we use SNAP - based on our experience with 2nd and 3rd graders, In previous such workshops not all participants had laptops or tablets, but some without those did have smart phones.

[brianharvey]

Wow! 2nd grade! You're braver than I am; early childhood scares me (preoperational and all that).

Does "not all" mean fewer than half? I would pair people without big screens with partners that do have them. They'd do better in pairs even if you had computers to go around.

I wish I could come to your workshop! I want to know more about what you do with the kids. Do you have a curriculum? In my elementary school work I've been pretty loose, just "here's Scratch, here's how you click two blocks together, go!"

[jcaldw737]

Thanks, I can see that is a great idea about pairing!

Here is a 15 minute demo of what we do with the kids.

[http://tinyurl.com/ezSNAPdemo833]

We do work one on one, but over the past years with LOGO and other things we have been able to find volunteers to do the instructing - sometimes in small groups rather than one on one. I'd greatly appreciate any comments you have on the demo or other things.

[jcaldw737]

The link didn't seem to work in the previous comment, here it is again.

http://tinyurl.com/ezSNAPdemo833

[ToonTalk]

I've tried running Snap! on Chrome on my Android phone (version 7.1.2). If I try to create a variable or a block nothing happens when I finish entering the name and click the arrow to indicate I'm done. No variable is created. The block is still waiting to being given a name.

Also unlike most pages I can't use a gesture to zoom on the Snap! page.

[DyslexicAwe]

Here http://snap.berkeley.edu/snapsource/snap.html#present:Username=kinestheticlearning&ProjectName=ezSNAP_animated_movement_blocks is my remixed version of your blocks for young users, mine are more animated Move, Draw, and Turn blocks, that behave more natural (and thus more familiar to children, who are not accustomed to unnatural "all at once" movements of ordinary Snap!/Scratch movement blocks). I hope you like them. I also left a comment under your video.

[brianharvey]

Huh, that's interesting. We do have the GLIDE block for smooth motion, but not the equivalent for turning. That's a good idea.

We do share your intuition about turning, though, in our curriculum: http://bjc.edc.org/bjc-r/img/1-introduction/PolygonalRacetracks_img/RaceTrackTracing.gif

We inherited the all-at-once motion and turning from Logo. In retrospect this is a little surprising, since Papert talked all the time about "body-syntonic" turtle motion, meaning the use of turtle-relative coordinates rather than stage-relative Cartesian coordinates.

We should consider doing slow moves and turns in Visible Stepping mode. Could you say more about the use of the ghost effect in your animations? Thanks.

[DyslexicAwe]

It didn't occur to me (until you have pointed out above) that there is an inconsistency between the Papert's ideas and an implementation of these ideas in Logo.

I guess, until Logo's turtle was a little robot, probably no one noticed that it was not possible for it to do unnatural all-at-once motion simply due to laws of physics, but after the Logo's turtle became a dot on computer screen it suddenly became possible for it to be in one place at one moment and magically appear in the next moment quite far away from initial position. Which is unnatural at least in our macro world and so a strange phenomenon, known in micro world (quantum tunneling), can not be accepted as an excuse for Logo's turtle to behave as a quantum particle tunneling from one position to the other.

Re ghost effect: I tried first to use the more animation-appropriate "blur motion" effect - watch the explanation into 11min 54secs in the following video https://www.youtube.com/watch?v=2ScUIpzswbE&t=11m54s&list=PLkHPPpAaV6zaG5vTzQI2mtmODxNGRHpu2&index=2 but in that case I shouldn't blur the whole turtle, so in order to indicate that turtle is in-motion at that particular moment (even if you take a still screenshot of it) I used the (simpler) ghost effect instead of motion blur.

Re using the GLIDE block: even if the block didn't require absolute coordinates of the final position to be known in advance, which it does and I didn't want to make the calculation, I still would not use it because I wanted the turtle to make an extra step and bounce back to the final position in accordance with another principle of animation that is explained into 33secs of the next video https://www.youtube.com/watch?v=4OxphYV8W3E&t=0m33s&index=1&list=PLkHPPpAaV6zaG5vTzQI2mtmODxNGRHpu2

Thanks for finding the animated versions of the motion blocks consideration-worthy.

[jcaldw737]

Thank you for the interesting thoughts about slowing the motion, and for your animated version.

[ToonTalk]

The challenge is that in some contexts one wants physically realistic turtle motion and sometimes one wants to draw complex designs that should run as fast as possible. To be fair to Seymour, in the late 1970s he and Marvin Minsky worked on a computer with hardware vector processing (the 2500 and 3500) where turtles had a speed. If the speed was small then forward and right took time - if very large then practically no time.

I too am a big fan of using animation principles but in my mind they should be built on top of a speed oriented set of primitives that do no blur or bounce back. Suppose a user is using a sprite that is a balloon or fish or rocket -- would bounce back be appropriate? Or a cat walking in a circle?

Glide seems like a poorly designed primitive. It encourages Cartesian coordinates over turtle geometry. And is duration instead of speed the right way to control motion?

[brianharvey]

I agree that glide should be in turtle steps rather than endpoint, but that's not hard to build as a custom block. And don't worry, we're not going to slow down the motion primitives; that, too, could be a library. No new libraries until 4.1 is out, though.

[DyslexicAwe]

tt:

Glide seems like (...)

bh:

I agree that glide should be (... ...) as a custom block.

I've googled and Jens tweeted in November 2016 exactly about his (custom-made) turtle-geometry Glide block

---

Edit: Are you going to pack it into the above mentioned (post-4.1.) "Animated Motion Blocks" library?

[ToonTalk]

Nice.

Wouldn't it be better to replace

with

?

Though for the parallel with the 'cos' call I would like to have a unary negation operation instead of swapping the arguments to the subtraction operator. Interesting that there is no negation operator.

[brianharvey]

We've talked about monadic minus. Jens thinks it's unnecessary because it's so trivial to write it as a custom block. I've been arguing to get rid of the empty=0 rule for arithmetic blocks (because empty means something else in HOFs), so to me it's more important.

[DyslexicAwe]

Just an idea to play with: what do you think - in the context of 1st&2nd-graders, only, of course! - about replacing degrees-based Turn blocks with easier o'clock-based Turn blocks as shown in the project linked below? http://snap.berkeley.edu/snapsource/snap.html#present:Username=kinestheticlearning&ProjectName=A_kids_friendly_clock_directions_instead_of_degrees

[ToonTalk]

That is what Scratch Jr did. I'm unconvinced that it is necessary but have yet to read the research on this topic.

[cycomachead]

First off, I'm very much enjoying reading this thread! :)

Just an idea to play with: what do you think - in the context of 1st&2nd-graders, only, of course! - about replacing degrees-based Turn blocks with easier o'clock-based Turn blocks as shown in the project linked below?

I think in the context of young children a click makes sense -- though I'm not sure how long this analogy will hold. It's been a while since I've been in any elementary age classroom, but I don't expect most kids growing up today see many analogue clocks. I'm only in my 20's and while I distinctly recall learning the clock, it was definitely something that I remember feeling was harder than necessary. (i'm young enough to natively know digital clocks.)

I like the approach that Scratch 3 is taking, where there is a visual circle which allows you to draw out the degrees for the point in direction block. You can play with it in their beta: https://llk.github.io/scratch-gui/

I'm not sure how "math-y" the projects of young programmers get, but if you need anything more precise than 30º increments, I personally find using time-based arithmetic to be more confusing. (Is 45º 1.5 or represented as 1'30" or something else? It's not so much that kids would be trying to convert, but depending on the full representation, I think things can get more complex than learning about degrees.)

[DyslexicAwe]

Thank you for the link to Scratch 3. I like its approach! If I am not mistaken, the Michael who (Jens says here) has created the Play note block is actually you? Maybe you will some day create a (Scratch 3)-like point in direction block, too :-)

[jmoenig]

while still not perfect wrt to pinch zoom (which does work, btw, but it's a little bit hairy to coordinate) the issue of entering text into input fields on Android has now been resolved as of https://github.com/jmoenig/Snap/tree/v5.0.6

[brianharvey]

YES!!!! <fist pump>