search

jmoenig / Snap

a visual programming language inspired by Scratch
http://snap.berkeley.edu
GNU Affero General Public License v3.0
1.51k stars 745 forks source link

Impossible to change the order of blocks in the pallete #271

Open joefarebrother opened 10 years ago

joefarebrother commented 10 years ago

It get's a bit annoying when i am working on different parts of a project at the same time and I want each set of blocks that are logically related to be near each other but they're not. It's also annoying when halfway through I decide I need to import a tool library, and my blocks end up being mixed with completely different blocks in the palette.

studej commented 10 years ago

Is this still actual when we have search functionality now?

I agree that palette is not well designed but the problem of finding users blocks is not a problem now.

marwahaha commented 10 years ago

probably okay to close, although tool libraries mixing with original blocks can get messy

studej commented 10 years ago

I realized that this is still needed. Sometimes one custom block uses another and If you can order them then student can easily understand how the whole thing was created because he will visits blocks in right order :-)

brianharvey commented 10 years ago

I definitely would like this, especially for the tools library but for users too. I can imagine some trouble cases where multiple libraries are used in the same project and they collide, but that can be worked out.

cycomachead commented 10 years ago

I don't see collisions happening if we do this correctly.

For ordering, we would simply led users drag and drop his/her own palettes to be the desired order, right? Then that setting would be saved (per-project, I imagine). Any new blocks could be added to the bottom as they are now, and a user would be free to re-order as s/he wishes.

The UI issue arrises whether this is a project level, or user level setting. I'd really vote for projects because this is VERY handy for curriculum and small demos and such.

(Later if we need user level settings - for new projects or something - we could work on that, bit I don't know if it's necessary for a while.)

brianharvey commented 10 years ago

Definitely per-project and, more important, per-library.

What I meant by collisions is this: How do we store the order? It can't be the complete order because that will change as new blocks/libraries are added. It'll be "put this block right after ITEM () OF ()" or something. And another library might say the same thing.

cycomachead commented 10 years ago

What I meant by collisions is this: How do we store the order? It can't be the complete order because that will change as new blocks/libraries are added. It'll be "put this block right after ITEM () OF ()" or something. And another library might say the same thing.

Ah, well, I don't think we would be able to solve the problem 100%, but here was my thought.

  1. Whenever a library is added, all blocks are added to the bottom of the palette in the order the library defines.
  2. A library can only specify the relative ordering of its own blocks. IE, the tools library wouldn't know anything about users' other blocks. And if it wanted the for block to be first in Control, it would be the first block added at the end of Control, but library couldn't say "put for above broadcast".
  3. The (de-)serialization for libraries would actually be the same as it is -- blocks are loaded in the order they are defined in the XML file. Authors can change the ordering by sorting the blocks before they export them. This would be done either in each palate or (better, IMO) in the export blocks dialog via DnD.
  4. User preferences would simply need to be array of block specs saved with each project.

So, this isn't as advanced as I think what you might want to happen, but I think it's ok for version 1 of such a feature. Let's say tools says "for is the very first block!" even without a conflict, as a (nit-picky) user would not be pleased if my sorting got reordered. It would be confusing.

As it is, I'm a little uncertain about this idea for the sharability of projects. It still think it's great but I see this case for users / students as they work on projects, especially if they are loading files given to them: 1) Project 1: Welcome to Snap!. Here's the primitives. 2) Project 2: Let's focus on "Conditionals" -- ok those blocks are moved around. Maybe some others are. 3) "Loops!" -- new ordering of blocks. 4) "Sorting lab" -- something with libraries imported that has blocks in yet another order. 5) Personal project. -- default set is easy to use. 5.1) Imports a couple libraries -- "WHERE THE HECK IS THIS BLOCK?!" without any order to blocks it can be very hard to find them.

I personally, have relied upon my knowledge of the block ordering in Snap! to use it quickly. I can't look at "Control" and quickly pick out "repeat" or something. For me, there's too much going and it's cramped. (Zoom helps, at least personally, but that has other issues).

tl;dr (I guess as I explained, this is what I was trying to say): I'm worried that if every project a user opens has a different block order, things will get very confusing as people can't find blocks. How do they discover new blocks?

Still, I think this could be cool, and would save many power users time, but I've worried about what happens if we aren't careful. I might have just convinced myself to vote against this. I don't know...maybe I'm overthinking this.

brianharvey commented 10 years ago

No no, the useful thing is precisely for libraries to be able to position their blocks among the primitives. For example, from tools:

IF ELSE reporter goes right under IF ELSE command. FOR goes right under REPEAT. The other Control blocks stay at the bottom.

JOIN WORDS goes right under JOIN. The other Operators blocks go under LENGTH OF.

FOR EACH goes under REPLACE. EMPTY? goes under CONTAINS. The other Variables (list) blocks go under ALL BUT FIRST OF. (The organization of the primitives is: first the blocks that are for linked lists, then the blocks that work for both kinds, then the blocks that are for dynamic arrays. So, maybe FOR EACH goes in that middle section too, depending how it's implemented.)

cycomachead commented 10 years ago

Ah, well, I feel like this is a separate issue, at least somewhat.

My solution would be to allow each library to contain the ordering of blocks for each palate. Then when you import, Snap! would have to merge each pair of category lists. Not sure what the best solution is, but I think Linus Torvalds knows.

(And really, I think we'd just have to pick a merging algo, implement it and then decide how to resolve conflicts.)

JOIN WORDS goes right under JOIN.

I'd nitpick about the confusing-ness of having both these, but OK.

joefarebrother commented 10 years ago

There could be a search feature to help find specific blocks.

On 11 July 2014 07:37, Michael Ball notifications@github.com wrote:

Ah, well, I feel like this is a separate issue, at least somewhat.

My solution would be to allow each library to contain the ordering of blocks for each palate. Then when you import, Snap! would have to merge each pair of category lists. Not sure what the best solution is, but I think Linus Torvalds knows. https://github.com/git/git

(And really, I think we'd just have to pick a merging algo, implement it and then decide how to resolve conflicts.)

JOIN WORDS goes right under JOIN. I'd nitpick about the confusing-ness of having both these, but OK.

— Reply to this email directly or view it on GitHub https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/issues/271#issuecomment-48702479 .

cycomachead commented 10 years ago

There could be a search feature to help find specific blocks.

There is indeed! :) Use Control-F to get to it.

My issue with search however, is that it doesn't actually help users find a block if they don't know it exists. (The UI for search is also still impossible to self-discover so that makes it a problem, but that could be solved.)

studej commented 9 years ago

I don't think that mixing custom blocks with primitive blocks is good idea :X In next project I will miss those blocks, really. And who should figure out which kind of library I should import to bring that block back into my project --> creepy. But libraries sounds like different issue, although there is connection to this.

What about this for user? It is taken from ExportBlocks window with some new buttons. Ordering is this design per palette, so for another category user must open that window again. organize_custom_blocks2