Block Picker takes up too much space

[JohnsonMyton]

What Happened

Hello! Love the idea of the project, wanted to add one of my first, instant thoughts. The amount of space for the actual blocks is pretty small, and on my students computers it's even smaller. One of the issues I think is that the gifts take up too much space -

Spec

The Block Picker should be a single area. Currently it has 2 columns: one for the categories (left) and one for the blocks themselves (right).

Convert the category selector buttons (currently first column) into title bar buttons. When clicking a title bar button, the page scrolls to show the blocks of that category. There is no need for subcategory buttons (eg. Logic | Conditionals), just category (eg. Logic).

The title bar buttons should be icon only, with a tooltip for the category name. Each category must have its own distinguishable icon. And colored with the category color.

References

• Use this mockup (left image) for reference: Block Picker takes up too much space #131 (comment)
• Use icons from https://developer.gnome.org/hig/guidelines/ui-icons.html or provide custom ones. They must be imported to the project as SVG files.

[manuq]

@JohnsonMyton thanks for your student's feedback! Yes, I think this can be improved by implementing subcategories. Currently the first word is being repeated to simulate subcategories in the single hierarchy, taking too much horizontal space.

[dsd]

@JohnsonMyton what's the specs of the students machines? And the screen resolution?

Excited to hear you are considering this for use in education context. Could you reach out to me at [email protected] - I would love to know more of the context. We're also developing this for learners but haven't manged to expose many students to this yet because of summer break.

[cassidyjames]

A quick and easy change here might be moving the category to the end of the line… so you'd have:

Lifecycle
Position | Transform
Rotation | Transform
Scale | Transform
Modulate | Graphics
Visibility | Graphics
Viewport | Graphics
Sounds
Input

Then users who collapse the width of that column can still see the most useful bit.

If we want to get more interesting, we could consider relying on an icon + color to group them into their respective groups instead, dropping the category from the label (and/or moving it to a tooltip). This would allow us to better use the space while still keeping a pretty strong association between blocks of the same category.

The GNOME UI icons are public domain, so we could lean on those for each category. Something like this:

[manuq]

@cassidyjames what do you think about the implementation done by @DoomTas3r here? #270

I have tried it and although it helps, I still find odd to have 2 columns in the tab:

If you think this is an improvement we should merge. Thanks @DoomTas3r for your contribution!

[manuq]

@cassidyjames please also point @DoomTas3r to the SVGs of the GNOME UI icons so the current placeholders can be replaced.

[ch0m5]

These are a couple quick mockups, but if having two columns feels odd and the goal is to maximize ease of navigation and space, we could use Icons and Sections to represent Categories and Sub-Categories, respectively. The 1st as Tabs with icons, and the 2nd as sections in a column list.

(Note: The left image's Selected Category Tab should be Logic, not Conditionals.)

Categories are represented as icons. Once a category is selected, a Scrollable column is displayed below it, listing all blocks that belong in that Category, ordered in their respective Sub-Categories. If you hover over an icon for a bit, a tooltip appears showing you the Name of the Category. (Having the name of the selected Category be visible is an idea to make it easier to see which Category is selected, but completely optional.)

I think this approach would minimize the space the block "encyclopedia" takes, granting a lot more space to block coding, without sacrificing readability. Icons are faster to read than Labels, the latter's main purpose is learning what the icon means, but you can do that with a Tooltip as to not sacrifice screen space in the process.

[manuq]

@ch0m5 I like it! They look like tabs. Could they even be standard Godot TabBar? In particular if TabBar already has logic for adding scroll buttons when the icons overflow.

And I don't think that the sub category list is needed at all. The user can just scroll to find the other sub categories like Comparison, Boolean.

[tindrew]

I'll move what I had here from #358 . My thought was there needs to be a search bar so people could search through blocks, especially since that category list is going to grow over time.

This is the mockup I did of a searchbar which shows blocks as you search:

When I was referring to collapsing, I should have clarified: callapsing the category/block sections is nice, but currently serves no purpose because you can't really use the right hand side for anything other than arranging blocks and duplicating/deleting them. So either having a search bar where you can search for blocks, and then drag them from the popup that shows them as you search is needed, combined with the above idea of having icons instead of a long list of categories taking up all that space.

There's another idea where you could right click/press and hold in the canvas area where you place blocks (not sure what it's called) and get the ability to find/click on a block for placement.

[DoomTas3r]

I wanted to know if anyone had opinions about this layout:

• Removed labels
• Removed subcategories

It reminds me of Scratch's layout, but using icons

[tindrew]

I like the icons, id say combine it with a search bar feature and roll with that.

What would be nice too is an "auto-open" feature where hitting an icon would pop open the block drawer if you have it collapsed.

[DoomTas3r]

I made these icons to use instead of the placeholders:

I'm open to suggestions for alternative designs

[tindrew]

I made these icons to use instead of the placeholders:

I like these designs very much.

My question is, who makes the decisions on what does and what doesn't go into the main project? I'm considering creating a fork(I have 3 people willing to dev on it from the current Redot team including myself). I think our use cases are different enough(we're looking at mobile usability, and overall game dev with the tool vs strictly being a springboard for students learning to code.

I'd like to know what the process is for accepting PRs as we would definitely want to share any work we do on it.

[DoomTas3r]

I think that the Advanced checkbox can be used to include the more practical features that beginners wouldn't need to see

As for accepting PRs, generally, anything that benefits users without impeding the workflow of a beginner can be considered. My accepted contributions related to the zoom buttons, the context menu, and block additions. Some specifics that were asked of me by @manuq were to keep the commits concise, make their descriptions informative, and to discuss new unique features before considering a PR

In practice, that means opening a PR, linking a related discussion if necessary, and waiting for a member of Endless to accept, give feedback, or make their desired edits. Usually they're busy, but they'll be happy to accept if the PR is easy to review and clearly improves user experience

[wjt]

My question is, who makes the decisions on what does and what doesn't go into the main project?

Currently the project is maintained by the tech team at Endless OS Foundation. We decide what goes into the project, guided by this document and our learning team's needs more broadly.

I'm considering creating a fork(I have 3 people willing to dev on it from the current Redot team including myself). I think our use cases are different enough(we're looking at mobile usability, and overall game dev with the tool vs strictly being a springboard for students learning to code.

Do you think that your goals around mobile usability & general-purpose game dev are in conflict there? Can you give some examples of changes you would want that would conflict with our goals?

(Personally I like the mockup above.)

It would be nice to avoid having a fork, though of course you're free to create one.

I'd like to know what the process is for accepting PRs as we would definitely want to share any work we do on it.

As @DoomTas3r says above.

[manuq]

@DoomTas3r I like the layout with icons too!

[cassidyjames]

I also like it. To clarify, that's the state of #270?