Hi,

I'm using Scratch (version 1.4) to teach kids. I do summer camps where we code in scratch for a total of 15 hours, and I've taught a lot of kids, and seen the same UI challenge trip them all up. I hate to see them fight the UI when they are having so much fun writing games, so I seek your help, oh gurus of the advanced topics board. Please shine your wisdom upon me!

If there is a Scratch mod that addresses this UI issue, please tell me about it! I've tried all the popular ones and none of them seem to address the UI. Alternatively, if there are any Squeek Gurus out there who can make these mods, many kids (and I) would be very thankful.

From my perspective as someone who's taught over 100 kids to code using Scratch, this mod would make a huge difference in making Scratch into a more effective teaching tool.

THE SUGGESTED MOD: Make it possible to remove a SINGLE BLOCK from a stack when editing code, without having the Scratch UI assume they want to grab all the lines below as well.

WHY: When kids get to the point where they have moderately complex code, with a couple of nested loops and maybe an IF/ELSE control block, they'll need to remove a single line of code. This turns out to be rather tricky for them, because as we all know, when you grab a block from your code stack, scratch assumes the user wants to grab that block AS WELL AS ALL THE OTHER BLOCKS BELOW IT, to the end of the control loop or if statement. To make matters worse, the control loop or IF statement “closes up the gap” and scrunches all the code below upwards, making the user lose the visual on the structure of the code. We've all become adept at navigating this quirk of the UI, but for new users, it really messes them up.

All the kids I teach run into this problem around 3 to 6 hours in, when they're writing pretty complex code. All they want to do is replace one line, but 9 times out of 10 they accidentally do a lot of collateral damage to structure of their code, because they need to put a whole bunch of other lines back, and the place where they came from has suddenly gotten smaller. This ends up creating tricky bugs and creating a lot of frustration.

The bottom line is that it takes most of them a few hours to really get the hang of it so they can just code without thinking about the UI, and some never really do. The kids shouldn't have to fight the UI.

IMPLEMENTATION SUGGESTION: One solution would be to have a button that turns off this “grab all the lines below and scrunch up the control loop” function so kids can move code around and keep the structure stable. The button could be called “edit mode.” When edit mode is turned off, all the loops could scrunch up again and close any gaps where code blocks were removed but not replaced. Yes I know this is a non-trivial change. But it would be a non-trivial benefit, from what I've seen. You can explain to the kids this trap, and some will get it, but in the heat of the debugging battle when they're excited about a new feature and their loops get messed up, it's a disaster.

SO, are there any Squeak Gurus out there who can help me out with one or more of these mods? Alternatively, are there any existing mods that do this?
Thanks in advance.

Hey, nobody can make a mod for you, but I can help.
So, what types of diferences are you thinking? And please change a lot of Scratch, since
Its logo, and stuff are copyrighted. First steps into squeak coding:

as much as i get what you are saying, they have to learn to adapt to the ui.
In my opinion learning to go around the challenges of a ui / coding language is important should they choose to go on mainstream scratch or another language.

In retrospect I should have actually posted my suggested mods into the “suggest a feature” thread. I was really hoping there might be a mod already out there with one or two of these things already implemented, and was hoping someone might know about it, but alas. Thanks anyway. I'll cut down my TLDR post to describing the two feature suggestions and repost there.

My technique, which works most of the time, is to drag the code below up and over the block you want to remove.

For example, to remove the ‘say’ block drag the ‘turn’ upwards. The ‘say’ falls to the bottom where it can be removed.

when this sprite clicked
move () steps
say [] for (2) secs
turn right () degrees

when this sprite clicked
move () steps
turn right () degrees
say [] for (2) secs

I'd like to add my vote to this suggestion - I've been “working around” the issue and just accepted that that was just the downside of Scratch (as syntax errors are the downside of text based languages).


I think we'd need to try a few things out to see what technique would be best but could potentially be a big win

Simon

Whats this ?

Not sure how the coding is done behind scratch, but the normal UI techniques here would be to use modifiers (alt, shift, ctrl) with the drag to give another meaning to that drag.

On Windows the shift modifier means move, the ctrl modifier means copy, and the alt modifier is left over for the application to choose.

@magpie5212 I like the modifiers approach. That's a good idea.

Agree with SimpleScratch & others the key to good UI design is to “try a few things.” The very best way to do that, is with real live users on early prototypes. Saves a lot of time. Kelly Fraznik of Blink Interactive is a genius in this area and the best I've ever worked with by far. Lots of great knowledge can be gleaned from his site.
http://www.blinkux.com/insights/

Don't get me wrong, the Scratch UI is a work of genius itself, it's just got one or two remaining “low hanging fruit” which, if fixed, are potential huge wins. Addressing this is one of them.

@magpie5212's earlier post: I know, that's what I teach them to do in my classes. It works really well when the code is simple. But watch an 8 or 9 year old try to modify something with 2 or 3 nested loops. Even if they know what they're doing and are careful, it's a shock when everything scrunches up and they can't see the hole where their code came from. If they're hurrying and/or don't know exactly what they're doing, it's a disaster. The chances of them putting things back together the way they were are slim.

To others who say “Struggling with the UI is part of coding, pay your dues!” I say with a sigh, “Spoken like a true engineer. Please stop being so exclusionary. It doesn't have to be this way. I'm using this tool to teach kids, and I'm an engineer, and I'm here to tell you, it could be engineered better. There are plenty of chances for the world to teach them that things are hard. We don't need to teach them that. We need to teach them how to code, and if the UI is in the way, we should make it better.”

But alas, I don't have the time to learn to speak Squeak. Too busy teaching kids to code with Scratch. (a wonderful tool which I love)

Coder85 wrote:

To others who say “Struggling with the UI is part of coding, pay your dues!” I say with a sigh, “Spoken like a true engineer. Please stop being so exclusionary. It doesn't have to be this way. I'm using this tool to teach kids, and I'm an engineer, and I'm here to tell you, it could be engineered better. There are plenty of chances for the world to teach them that things are hard. We don't need to teach them that. We need to teach them how to code, and if the UI is in the way, we should make it better.”

Reminds me of the time back in the 80s when I worked with Microsoft. My job was to document an API to part of Windows. I argued with them a lot about simplification, symmetry and consistency. The argued back that if it was too easy to learn then anyone could do it - not just engineers.

LOL Classic! Love it

Another idea would be to introduce the notion of selection into the UI. Allow one or more blocks to be marked as ‘selected’ with a click, shift-click, or ctrl-click etc. The default click could select the block to the end as the drag does now. But a ctrl-click would change the selection of a single item. Once you have selection shown you could perform actions on the selection in a clear way.

All good ideas; I don't know what would work best, but that's what user UI testing is for.

But the problem of excess selection is only half the issue. The other half is the instant and arbitrary mobility of the code below what's selected. That's what's so shocking and confusing to them.

In other words, the way the loops close up when you take something away, that's what kills them, especially when the loops are nested.

To address that issue, how about this: When they drag that code away from other loops, it should leave a hole where it used to be, so they can change that bit, then reassemble things by putting it back in the hole. That's what they're expecting ,and that's not what they're seeing.

For all you visual learners out there, here's what we're talking about.

This is actual student code. He's only got 3 nested loops here, but it illustrates the problem. Some of my kids have much more complicated stuff going on.

Here's the BEFORE picture

when green flag clicked
repeat until <(truck life) = [0]>
go to [battle truck 1 v]
point in direction ([direction v] of [battle truck 1 v])
show
repeat until <touching [edge v]?>
move (19) steps
if <touching [tank1 v]?> then
change [youre life v] by (-0.5)
end
end
hide 
end

Now let's say young Abe wants to grab that IF statement. Maybe he's thinking it should be WAIT UNTIL or whatever. Kids do that. He's learning.

So he grabs that block. Here's what the remaining code changes to. Instantly.

AFTER

when green flag clicked
repeat until <(truck life) = [0]>
go to [battle truck 1v]
point in direction ([direction v] of [battle truck 1 v])
show
repeat until <touching [edge v]?>
move (19) steps
end
hide 
end

Now he's holding his IF statement to the side and he's wondering, "Wait, where was this a minute ago? When I make my change and want to put it back, where does it go?

if <touching [tank1 v]?> then
change [youre life v] by (-0.5)
end

Keep in mind this is a simple example. Now imagine a long stack of code blocks with maybe 4 or even 5 nested loops. Try to make one change. Tricky. Very tricky. Unnecessarily so.

There must be a good reason they chose to do it this way, perhaps to make it easier for people to delete code. But it makes it much harder to change code, and from what I've seen, changing happens more often, especially during debugging. There must be a better solution. I'd like the issue revisited and some new things tried and tested on new users.

Those of us who've been coding in scratch for hundreds of hours can't even see this problem any more, we've gotten so used to it. But since Scratch is a learning tool, I think this should be looked at from the perspective of new students.

Like the ghost space idea.

Another thing that would help would be to have Undo - there is just Undelete at the moment.

Ah!

Undo, now THAT would be useful!

Yup.

I'd like a right-click option that lets you delete a single block. If you're using 1.4, try asking someone like @LS97 or @jvvg – they're pretty good at Squeak and can probably help you out. And something like this wouldn't violate the modifications-not-uploading-to-Scratch guidelines, because it's only a UI change, not a programming change.

scimonster wrote:

And something like this wouldn't violate the modifications-not-uploading-to-Scratch guidelines, because it's only a UI change, not a programming change.

Wrong. <http://info.scratch.mit.edu/Source_Code#trademark>

Scratch Trademark Policy wrote:

“Substantially Unmodified” means the source code provided by MIT, possibly with minor modifications including but not limited to: bug fixes (including security), changing the locations of files for better integration with the host operating system, adding documentation, and changes to the dynamic linking of libraries.

Yeah any change to the Squeak code is a change in programming, which makes it a mod– thus it's no longer Scratch. But, this sort of suggestion is exactly what I was looking for! I originally was looking to find a mod that had this, so by definition, I've accepted the downsides of using a mod (not being able to call it Scratch, losing upload ability) to get this. Thanks for the referrals! Cheers.

I do wish that the MIT guys would consider adding this to the main code tree (I posted it on the suggestions thread too), and it sounds like I'm not alone. If you agree, chime in!

Just use the scissor tool at the top of the screen.
With the scissor you can remove one block of a stack.

So, you don't need a mod.