Add Search Bar to Blocks Editor for Faster Navigation

[Akash_Gite]

Overview

The Blocks editor currently lacks a search functionality, requiring users to manually navigate through multiple categories (Control, Logic, Variables, etc.) to locate specific blocks.

While this approach works for small projects, it becomes inefficient and time-consuming as project complexity grows.

Problem

• Manual navigation slows down development
• Difficult to locate specific blocks in large projects
• High cognitive load, especially for beginners
• Inconsistent UX compared to the Designer, which already provides a search feature

Proposed Solution

Introduce a search bar in the Blocks editor (similar to the Designer search bar) that allows users to quickly find blocks by name, functionality, or associated component.

Left: Designer search (existing) | Right: Blocks editor (no search)

Suggested Features

• Real-time filtering of blocks based on search input
• Support for both built-in and component-specific blocks (e.g., Button1.Click)
• Fuzzy matching for partial or approximate queries (e.g., "speak" → TextToSpeech blocks)
• Highlighting or preview of matching blocks
• Clicking a result scrolls to the block or inserts it into the workspace (optional enhancement)

Benefits

• Faster development workflow
• Improved usability for large-scale projects
• Better accessibility for beginners
• Consistent user experience across Designer and Blocks editor

Additional Context

The Designer already includes a search feature for components, which significantly improves usability. Extending similar functionality to the Blocks editor would provide a more cohesive and efficient development experience.

Open Questions

• Should search results replace the toolbox temporarily or appear as an overlay panel?
• Should selecting a result auto-insert the block or just navigate to it?

I’d be happy to contribute or help explore implementation approaches if this feature is considered valuable.

[ABG]

Have you tried the Text blocking feature yet?

[Akash_Gite]

Thanks for pointing that out!

Yes, I’ve tried the text block search (Ctrl + F), and it’s helpful for finding blocks already placed in the workspace.

However, my suggestion is slightly different — it focuses on improving block discovery within the toolbox itself.

Currently:

• Ctrl + F helps locate blocks that are already used
• But it doesn’t help when trying to find a block that hasn’t been added yet

The proposed search bar would:

• Allow users to search across all available blocks (including component blocks)
• Reduce the need to manually navigate through categories
• Improve usability especially in larger projects

So this would complement the existing feature rather than replace it.

Would love to hear your thoughts on whether this distinction makes sense.

[ewpatton]

Typeblocking is a different feature than the block workspace search (Ctrl+F). Click on the workspace, and then begin typing the text of a block (e.g., sort). You will get a dropdown of all the blocks that match. It is also locale aware, so people using App Inventor in another language can search the translated blocks list.

[ABG]

Typeblocking

from

FAQ Section: Blocks Editor

Typeblocking video demo - MIT Blocks Editor needs Browser Popups for Typeblocking and Downloaded Blocks Images Finding hidden error or warning icons using Chrome Web Browser Inspector - TFO Searching in the Blocks Editor - Ghica 2019 Searching in Firefox - rfresh1011 2025 Sharing Blocks Though github.com - ABG Can't Select or Drag some blocks because of AntiVirus Deep Nesting distorts Blocks Editor; Use mutators Too Many Blocks - ABG How to poison the Blocks Editor using Printer Codes i…

[Akash_Gite]

Got it — thanks for pointing me to typeblocking, that helped clarify things.

What I’m thinking of is slightly different:

Right now, typeblocking shows text-based suggestions when typing, but users don’t see the actual block structure until they insert it.

It might be helpful if the suggestions also included a visual preview of the corresponding blocks, so users can:

• Quickly recognize the block visually
• Understand its structure before inserting it
• Reduce trial-and-error, especially for beginners

I’m planning to experiment with a small prototype by building on top of the existing typeblocking system to see how this feels in practice.

Would love to share results once I have something working.