HyperBlocks come to Snap! — UX for PX in CS4All

October 5, 2020 at 7:00 am 10 comments

Jens Moenig kindly shared with me a video announcing HyperBlocks that he’s added to the next version of Snap! The idea of hyperblocks is to support vector and matrix operations in Snap!, as in APL or MATLAB.

I’m interested in the research question whether vector operations are easier or harder for students, including considering who the students are (e.g., does more math background make vector operations easier?) and how we define easier or harder (e.g., is it about startup costs, or the ability to build larger and more sophisticated programs?). My suspicion based on the work of folks like L.A. Miller, John Pane, Diana Franklin, Debbie Fields, and Yasmin Kafai is that vector operations would be easier. Students find iteration hard. Users have found it easier to describe operations on sets than to define a process which applies the operation to specific elements. It’s a fascinating area for future research.

And, you can do Media Computation more easily (as Jens shows) which is a real win in my book!

They also have an online course, on using Snap! from Media Computation to Data Science: https://open.sap.com/courses/snap2

Soon after Jens sent me this video, I got to see him do this in real-time at Snap!Con, and then he and Brian Harvey won the NTLS Education Leadership Award for their work on Snap! (see link here). Congratulations to them both!

So here’s the question that I wonder: Who does Snap! work for, and who doesn’t it?

  • I find Snap! fascinating but not usable for me. I have tried to do what I see Jens doing, but have to keep going back and forth from the video to the tool. It’s not obvious, for example, where to get the camera input and how to use it. I’m sure if I spent enough time using Snap!, I’d get it. What teachers and students are willing to pay that cost? Obviously, some are — Snap! is popular and used in many places. Who gets turned off to Snap!? Who doesn’t succeed at it?
  • I attended some of the sessions at Snap!Con this summer: https://www.snapcon.org/conferences/2020. I was particularly struck by Paul Goldenberg’s session. He showed videos of a young kid (somewhere in 8-10) using Snap!. He was struggling to place blocks with a trackpad. Think about it — press down at the right place, drag across the trackpad without lifting up, release at the right place. This is hard for young kids.

These are important questions to consider in pursuit of tools that enable CS for All. UX for PX – how do we design the user experience of the programming experience.

P.S. Jens just sent me the link to his Snap!Con talk video: https://youtu.be/K1qR4vTAw4w

Entry filed under: Uncategorized. Tags: , , .

Award-winning papers at ICER 2020 explore new directions and point towards the next work to do Social Studies Teachers using Programming for Data Visualization: An FIE 2020 Paper Preview

10 Comments Add your own

  • 1. Ken Kahn  |  October 5, 2020 at 10:00 am

    Regarding hyperblock specific possible research questions, there are several that I would like to see explored. Are there interesting differences in understanding and fluency when using these linear algebra operations in a solely mathematical context versus contexts where the students are working with numbers that represent images, sounds, real-world data, Newtonian mechanics, or word embeddings (https://en.wikipedia.org/wiki/Word_embedding)? While I see many advantages to working with “data” instead of “just numbers” it does impose additional challenges (as, for example, Mark pointed out regarding how to get a list of numbers from an image).

    There is a deep and important mathematical idea behind hyperblocks, namely that arithmetic can be generalised to go beyond operations on single numbers but instead more complex structures can be added, multiplied, etc. It would not surprise me if students fluent in hyperblocks might find modern algebra more intuitive than those whose numerical calculations were oriented around iteration.

    Reply
  • 2. Jens Mönig  |  October 5, 2020 at 11:52 am

    Hi Mark,

    thanks for the – critical! – blog post. As you might know the idea to bring hyperblocks to Snap! arose out of actual issues we encountered over time, last earlier this year (when travel was still possible) as we were working with Bavarian teachers at the University of Erlangen. We noticed that instead of using higher order functions like MAP some kept trying to use arithmetic operators directly on lists of numbers, or – as we were doing Caesar ciphers – expected the UNICODE function to just auto-magically return a list of numerical values if applied to a whole text instead of just a single letter.

    As we noticed the pattern in these repeated misconceptions we dug up an old idea Brian and I had brainstormed about some years ago, and decided to experiment with changing our thinking rather than that of our audience, and accepting their errors as ours.

    We’re excited and scared what might come out of this. On my part the excitement of the mere fun to be had with hyperblocks still prevails (see my demo of using it to back-sample Pink-Floyd for a secret message in my Snap!Con talk: https://youtu.be/K1qR4vTAw4w), but we’re also terrified about confusing our users with such alien concepts that are unlike anything found in most imperative beginners programming environments.

    Reply
  • 3. gasstationwithoutpumps  |  October 5, 2020 at 12:29 pm

    I’ve found numpy’s conventions about vector operations fairly useful, and I can see it being a natural fit for Snap in several applications as Jens says. Many Python operators can be (and have been) extended from individual items to collections of items (not just lists, but sets, dictionaries, strings as lists of letters, …). Does Snap! have other collections and do the operators generalize the same over all the collections?

    I do see some risk of misunderstanding if multiplication (other than dot product) is included, as the lack of commutativity can be very confusing to beginners.

    Incidentally, drag-and-drop on a trackpad is not just hard for 9-year-olds—I’ve been struggling with it for over a decade. And it doesn’t help that the trackpad has multiple switches, some of which fail, so that only half the trackpad works on one laptop, and none of the switches work on the older laptop.

    Reply
    • 4. Jens Mönig  |  October 5, 2020 at 1:11 pm

      Hi Kevin,

      Snap! only has a single heterogeneous collection type named “list”, which internally is a hybrid data structure combining the behavior of a linked list with that of a dynamic array, depending on how you use it. Matrices / tables and multi-dimensional structures are constructed by nesting lists. This makes hyperblocks universally applicable in Snap! even though it’s not yet a fully pervasive concept, i.e. not every function is “hyper”. We’re still dipping our toes into this concept, eager to find out how users react to it.

      Reply
      • 5. bh  |  October 5, 2020 at 3:52 pm

        Well, hyperblocks work for datatypes built out of lists only if the structure is “all data”: if you use a list of lists as a matrix, then every atomic element is a value in the matrix. But if you build a hash table, say, with a header that says how big the table is and what hash function to use, passing that into a hyperblock will try to treat the header stuff as data. Your abstract data type needs a function that extracts just the data. So for example a sprite costume is such a data structure; it knows its dimensions and its rotation center as well as the actual pixels. But we have a PIXELS OF block that takes a costume and reports its list of pixels, and you can use that list in a hyperblock.

        About multiplication: The core hyperblock feature isn’t very smart about the math. Every dyadic scalar function, applied to two lists, just calls the underlying function termwise. This isn’t a dot product, isn’t a cross product, and isn’t a matrix product. It’s useful if you have, I don’t know, a list of unit prices and a list of quantities and you want a list of total cost per item type. Maybe that’s not the best example because even better would be to add those costs to get the total cost, which would be a dot product. But what the hyperblock does is commutative. If the underlying scalar function is commutative, then so is the hyper version.

        But in addition to this core feature built into Snap! 6.0 and up, there is also an APL library that provides almost the entire APL language (I don’t have an algorithm for matrix division yet… something to research in my copious free time). So that includes all the right multiplication things, including generalized matrix multipication that lets you use other functions besides multiplication and addition to compute each item of the result. One important use of that generalization in APL is to use Boolean operators instead of arithmetic operators, so you get a Boolean matrix product.

        What a block language doesn’t have, of course, is the notoriously terse APL syntax. Instead of Greek letters as function names we have longish strings that explain better what the block does, but makes a typical APL one-liner quite verbose. So we generally go in for more use of script variables to hold intermediate results.

        Jens’s use of hyperblocks in media comp doesn’t require much of a mental model; it’s not clear yet whether users will want to push further into the APL way of thinking. I was lucky enough to learn APL as a kid, even before I learned Lisp, so this is like a homecoming for me, but we don’t have a lot of other APL enthusiasts that I know about using Snap!.

        Reply
  • 6. bh  |  October 5, 2020 at 4:06 pm

    Oh, about Paul’s young kid finding dragging blocks hard: For young kids typing on a keyboard is hard, too! Luckily, kids are ferociously eager learners and will overcome such obstacles if they feel they’re learning from the computing experience beyond the input difficulty. We can help them by making the blocks bigger, which makes them easier to control on a tablet. (This is a Snap! feature.) Or we can give them a real computer with a mouse, instead of a tablet.

    Reply
    • 7. Mark Guzdial  |  October 5, 2020 at 7:57 pm

      Hi Brian,
      I’m making exactly that argument these days — I’m exploring alternatives to either written text or blocks! Both are great, but neither are likely going to be great for everyone.

      Reply
  • 8. Mark Miller  |  October 10, 2020 at 4:24 pm

    Snap! evolved from efforts to fix serious omissions in Scratch, such as the inability to define a function that returns a value and the inability to define your own blocks (later added). Scratch seems to have a “lower floor” but also a “lower ceiling.” Scratch’s biggest strength is probably its community; but also, Scratch was never intended to be a tool for teaching CS — it was intended as a tool to inspire creative. Mitch has emphasized that repeatedly, but the CSE community has seized upon it anyway. Snap! has a higher “ceiling” and demonstrates that the power of Scheme can be delivered in a block-based language. It restores powerful capabilities that were part of the original Logo vision but left out of Scratch (partly intentionally). We have used Snap! as a middle school option that enabled students to do this like easily control the Arduino Mega in our Liquid Handling Robots project (https://lhr.learningtech.org), even if they had no prior programming experience, enabling integration of NGSS Science and CS. I believe we might be able to have best of both worlds, through providing teachers the ability to easily hide more advanced blocks, but this ideas has not been widely embraced for whatever reasons. Snap! has been very successful in the AP CS Principles efforts as well. Since there is some evidence that even students who have had exposure to text-based programming can do better on some tasks with a block-based alternative, I would argue that strengthening features such as mapping functions over collections and providing matrix operations are appropriate and valuable in grades 6-12, and probably even in courses such as undergraduate CS for non-majors offerings. One thing that might help the community would be an attempt to reduce non-essential differences, such as providing the same rich library of artwork for sprites and the same features for user authentication and saving of files, making it easier for students who know Scratch to transition to the more powerful Snap! world.

    Reply
    • 9. bh  |  October 10, 2020 at 5:06 pm

      Thanks for the generous endorsement of our work.

      The ability for teachers to hide primitive blocks has been in Snap! for a long time. Some teachers love it, although I’ve never been a fan of the idea, because I think seeing things they haven’t had to use yet invites kids to dive deeper. What we haven’t embraced until just recently is the ability to build a closed microworld in which the student doesn’t have the ability to bring back the hidden blocks. Paul Goldenberg wanted that for his work with young kids, grades K-2, and commissioned a version of Snap! with that feature. The implementation isn’t yet robust enough for general release, but I guess that’ll happen sooner or later.

      It’s true, we haven’t kept up with the great Scratch costume collection, mainly because our existing costume chooser is too slow to handle so many costumes. But we know how to fix that, and will When Things Slow Down™.

      Interfacing better with schools is our top priority right now. The biggest problem is not technical but legal; schools want us to sign contracts promising to follow all the privacy rules, and although we do follow the rules, it’s hard for us to sign contracts, for reasons too boring for me to spell out here. But we’re working on that, and along with that effort we’ll learn to interface with the schools’ user authentication and learning management systems. (One of our developers does that in his day job, as it happens, so this shouldn’t be too hard.)

      The #2 priority right now is improving our community sharing site with things like commenting on projects. Here too the biggest difficulty is social rather than technical; we are resisting our Scratch-raised users’ demands for love-it buttons and similar encouragements to making Snap! a popularity contest, as has happened to some extent among Scratch users. We do not want to be Facebook!

      Reply
      • 10. Mark Miller  |  October 10, 2020 at 9:48 pm

        All great points, bh!

        Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 7,995 other followers

Feeds

Recent Posts

Blog Stats

  • 1,801,949 hits
October 2020
M T W T F S S
 1234
567891011
12131415161718
19202122232425
262728293031  

CS Teaching Tips


%d bloggers like this: