Attached comments disappear while dragging in and out of a block editor

[nathan]

Comments disappear when the blocks to which they are attached are dragged into or out of the script area in a block editor.

[jmoenig]

(Sigh). Nathan, you know Scratch and BYOB, and the source code. Comments are not parts (submorphs, children) of their anchor blocks, but merely follow their anchors around. This is important and useful in many contexts (e.g. When reifying blocks). Comments are layered /behind/ blocks so they can be attached zo blocks inside other blocks without overlaying them).

This is I want things to be, it's my design, not a bug.

Von meinem iPhone gesendet

Am 12.04.2013 um 18:36 schrieb Nathan Dinsmore notifications@github.com:

Comments disappear when the blocks to which they are attached are dragged into or out of the script area in a block editor.

— Reply to this email directly or view it on GitHub.

[nathan]

A software bug is an error, flaw, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. — Software bug (Wikipedia)

When I drag around a block with an attached comment, I expect the comment to be picked up as well (since it is attached to the block) and dragged by my mouse pointer, above other objects on the screen. Instead, the comment follows it around behind the other objects in the scripting area, and remains confined to the original scripting area in which the block was placed, unlike the block, which can be dragged anywhere onscreen.

Just because something makes the implementation harder does not mean it isn't a bug. I've explored the Scratch, BYOB, and Snap! source code, but that shouldn't (and doesn't) affect my opinion on whether something is expected behavior, i.e., whether it is a bug.

[jmoenig]

Oh go pick on somebody else :-)

[brianharvey]

On 4/12/13 9:52 AM, Jens Mönig wrote:

(Sigh). Nathan, you know Scratch and BYOB, and the source code. Comments are not parts (submorphs, children) of their anchor blocks, but merely follow their anchors around. This is important and useful in many contexts (e.g. When reifying blocks).

See, you're the immovable object. :-)

Seriously, since I don't know the source code, could you explain in words of one syllable (e.g., not "reified") why this behavior is good? Tnx.

[brianharvey]

On 4/12/13 11:33 AM, Nathan Dinsmore wrote:

Just because something makes the implementation harder does not mean it isn't a bug.

Nah, if the programmer did it on purpose it's a "misfeature," not a "bug." :-)

[jmoenig]

If the comment were a part of the block, wrapping a ring around it would let the ring surround the block with comment instead of just the block. Same with "Saying", "Thinking" and watching a block onstage.

[nathan]

There's no reason ringifying or say ()ing a block or script couldn't filter out attached comments…

[xtitter]

If you think to yourself "annotation" rather than "comment", the current behavior makes more sense -- plus, is looks more like an annotation. The issue of when metadata should stick to something or be removed isn't straightforward -- if you are adding an annotation about how a particular sprite uses a block, you don't want to keep it when the block moves to a new sprite. That is the sense I get from the look and feel of current snap comments.

[nathan]

if you are adding an annotation about how a particular sprite uses a block, you don't want to keep it when the block moves to a new sprite.

But you would want to keep it if you copied a script containing the block (and annotation) to another sprite. Even a single block could have nested reporters or argument values that the annotation discussed. It seems rather unlikely that whatever the annotation discussed would not apply at all if only the calling sprite were changed (which is what happens when you copy a block or script to another sprite).

If you're talking about the new help-tooltip feature, the block is (hopefully) use-agnostic, and annotations discussing particular uses of the block should be attached to those uses themselves (or the sprite in which the uses occur).

If you think to yourself "annotation" rather than "comment", the current behavior makes more sense

It still doesn't make sense to me—either the annotation shouldn't follow the block at all and shouldn't display a shadow, or it should follow it, display a shadow, and be picked up by the mouse.

[jmoenig]

It doesn't show a shadow.

I've spent months implementing various ways for sticky comments / annotations in Scratch 1.4, both integrating comments in the Morphic tree and keeping them outside. My own initial hunch (and several versions) were to integrate them, John's was to keep them separate. Eventually we agreed to keep them apart from the blocks, because it would give us better control of the following and placing behavior, and because of other complications arising out of integrating them inside blocks. For example, the bounds of an input slot (and of the space a reporter occupies when embedded in another block) is determined by the fullBounds of the reporter, i.e. the union of all its recursive childrens bounds. If comments were parts of their anchor blocks we would have to make special provisions to ignore embedded comments. John was against this, and he convinced me. Of course, keeping comments apart from the blocks has its own downsides, as you can see im bug reports and discussions like this one.

[nathan]

It doesn't show a shadow.

Erm…

More justification for why an attached comment should be picked up with its block: when I drag a block with an attached comment into the palette, it deletes the attached comment as well (even though I can't see it when the block is on top of the palette, because the comment gets clipped inside of the script area!)

Regarding the implementation issues: can't you add a boolean field Morphic checks for when calculating fullBounds, which causes it to ignore the morph on which the flag is set? (Doesn't/shouldn't it already do that for shadows?)

[jmoenig]

Oh, you're right, it does show a shadow.

Okay guys, I'm getting annoyed by this discussion. I can offer to remove the shadow and let the comment stay in place while you drag its anchor block afound (with the connector sticking out) and to align it once the block is positioned somewhere else. This is how the current version of Scratch 2.0 does it. Would this make you all feel better?

[nathan]

I still don't think that's the expected behavior. When I pick up a block with an attached comment, I expect it to stay attached to the block (no self-shadowing, displayed above other morphs like the block is) while I drag it somewhere else and drop it there.

Implementation-wise, does Morphic.js support grabbing multiple morphs with a single hand? You could grab them both and re-layout when the block is dropped.

[jmoenig]

Single-grab only for this version of Morphic, but it could be enhanced. There could also be other ways to grab both, e.g. Embed them into a temporaray container morph when picking them up. But I don't want to make Morphic more complicated by introducing multi-object grabbing.

Actually I think this is a non-issue. Nothing breaks if your expectations about shadows and layers don't perfectly match the displayed behavior, because as soon as you position a dragged anchor block in a scripting pane everything will be fine (and inline with your expectations) again.

[nathan]

Nothing breaks if your expectations about shadows and layers don't perfectly match the displayed behavior

Nothing breaks, i.e., the application is still usable, but it still doesn't feel right to the user because, as you said, it doesn't match his/her expectations.

[jmoenig]

I was only quoting you about user expectations, but I agree about not showing a shadow on anchored comments.

[nathan]

What I meant by this:

either the annotation shouldn't follow the block at all and shouldn't display a shadow, or it should follow it, display a shadow, and be picked up by the mouse.

…was that there were only two options which matched my expectations:

• the comment is completely detached (and never reattached); or
• the comment acts like it's part of the block and gets picked up, dragged, etc. like everything else in the script.

I would much prefer the second.

[jmoenig]

Don't limit your expectations to binary choices. :-)

Why on earth can't I have a comment following a block it relates to? It's exactly what I want. If you expected something else, allow yourself to be surprised, it works.

[nathan]

Why on earth can't I have a comment following a block it relates to?

You can. It just needs to follow it correctly, i.e., in the same way as the rest of the script follows the block: with a shadow, picked up by the hand, and above all other morphs.

[nathan]

Unattached comments display this behavior:

…as do blocks:

…and sprites:

…but attached comments do not:

Inconsistency (when the same gesture or action produces different results) can be very confusing for users, and make it harder for them to learn how to use the application and discover its features.

Attached comments behave like they are part of the script. They:

• follow the script while it is being dragged;
• are moved to the same place the script is dropped;
• are deleted when the script is deleted;
• are visually attached to the script by a line; and
• contain information connected with the script.

Therefore they should act like the other parts of the script do when the script is dragged.

[jmoenig]

Possible remedy, also for #8, is to place the comment on the World when invoking startFollowing(). I'll take it on.

[nathan]

Awesome—you may still get self-shadowing, though.

[jmoenig]

fixed. Should we open another issue for the still slightly overlaying drop shadows?