"Editor Tabs" Refresh

[carljbowman]

Overview

We would like to take another pass at the "Editor Tabs" design to increase the visibility and "tabby-ness". Of course the hierarchical prominence is a balancing act among the UI that we will continue to dial in over time

Language

• Rename "Blocks" tab to "Code" and add blocks icon
• Keep "Costumes" and add paint brush icon
• Keep "Backdrops" and add paint brush icon
• Keep "Sounds" and add paint brush icon

Icon Assets
tab-icons.zip

Prototype
https://invis.io/53GNSXUWQ6F

Sketches

Code Tab

Costumes Tab

Sounds Tab

Assigning @thisandagain for triage

[mrjacobbloom]

I really like the overlappiness of the tabs! Is the width of the Code tab always dictated by the width of the left column of the Costumes and Sounds tabs? It worked out well in English but I don't trust the word "Code" to be short enough in other languages for that to work out

[hedgehog125]

@mrjacobbloom Hmm, it could just be the icon and only say the text when you hover? Then it could be a lot longer.

[carljbowman]

@mrjacobbloom - Just a coincidence in the mock that things aligned nicely, but not explicitly apart of the design.

[kyleplo]

In the costumes tab, shouldn't it be more like this:

[sfederici]

I think there are some general problems with the new interface. The Scratch interface has always been YASWIMI, that is "You Always See What Is More Important". In Scratch 1 and 2 you always see blocks, even when working on costumes and sounds. In Scratch 3 instead you don't see blocks anymore when you move to costumes and sounds. That is wrong.

That said, I don't think changing the name of the tab from blocks to code is a good idea. Students will learn to think to code as blocks in Scratch. This is the main difference between coding with a standard programming language and Scratch. So, who is going to help using the word "code" instead of "blocks"? No one.

As for the block icon, it didn't mean much to me the one at the bottom left of the list of categories with the + sign. When I saw it the very first time I thought "what it is button for"? And I'm using Scratch since 2008. If you really want to use icons for blocks/costumes/sounds I think the blocks icon should be retougth.

[Kenny2github]

@sfederici there's a slight inaccuracy there. When working on costumes and sounds in Scratch 2, you actually can't see blocks. I agree that changing the name from Blocks to Code is a mistake, but that might be something for a different issue.

[sfederici]

@Kenny2github Yes, and this is most unfortunate. The best choice was the popup costume editor in Scratch 1, so that you could (correctly) see the paint editor only if you really want a costume to be different from the ones available in the library or imported or "shoot". You can do a lot of things just using the costumes from the library. The important parts of Scratch are blocks and sprites. So I welcome the sprite infos (coordinates, direction, etc) getting back visible all the time.

[tmickel]

@sfederici

The best choice was the popup costume editor

One significant advantage of the in-tab paint editor is that it allows rapid iteration and tinkering with costumes that is immediately reflected and fully visible on the stage. In the pop-up editor, going back and forth between editing a costume and seeing how that affects your project requires either a very small pop-up or clunky window manipulation.

You Always See What Is More Important

The desire to emphasize the most powerful part of Scratch makes sense, but I disagree that the palette needs to be "always seen" for Scratchers to realize their importance and utility! :) I would also not downplay the importance of powerful and usable tools for editing images and sounds. To my understanding, above all, Scratch aims to be about creating.

changing the name of the tab from blocks to code is a good idea

Traditionally it was titled "Scripts" --- it seems this has been iterated on a lot for 3.0 :) I am not sure I understand your point about "thinking to code as blocks." To my understanding, there is no "main difference" between a 'standard programming language' and Scratch beyond (1) the set of commands built to interact with the tinkerable Scratch runtime and (2) the graphical editor. Isn't Scratch "code"?

[sfederici]

One significant advantage of the in-tab paint editor is that it allows rapid iteration and tinkering with costumes that is immediately reflected and fully visible on the stage

In reality this is something that really drives me crazy. I very often start editing a costume (or a project) and then decide that this is not the best way to go for. The new "ultra-interactive" behaviour of Scratch (since version 2), that is projects changing even before saving and costumes being modified without actually having to save them, it is for me a very bad feature. I want to have to click an OK confirm button before costumes are changed or to select a SAVE option in the menu before a projects is actually changed.

I disagree that the palette needs to be "always seen" for Scratchers to realize their importance and utility!

My deepest desire with Scratch is that it could be used by people that weren't previously explained how the GUI works. So I was very sad when the sprite info area went hidden behind a "info" icon. Now the area is back, but the blocks are gone in some cases. I perfectly remember my very first approach to Scratch after having tried Alice. I was very happy that I could see a lot of things, but it took some time to me to discover what the "category" labels on top of the block list were for. So I like the "single list" of blocks, but it is to me very important that blocks (the most important part of Scratch) are always visible.

Isn't Scratch "code"?

I guess this is due to my way of thinking to good and bad coding. Scratch is the good coding that I learned to associate with blocks. Other languages (even block languages such as code.org or Alice or appinventor) are sort of bad coding. They do not guide you well, so that in a very short time you can get frustrated and abandon.