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 drake@endlessos.org - 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.