App Inventor‎ > ‎

Searching

Cecellia (Cece) Tsui, Wellesley College Class of 2018

Why Is Searching A Problem In App Inventor?

Currently, App Inventor provides no tools to search the blocks code within a program. In order to search for a particular block, users must manually drag the workspace with their mouse and look at each block. Although this may be a small problem for a simple program, users may find searching through a larger program much more difficult and time-consuming. Searching in App Inventor is thereby a significant problem. 

A user's default searching behavior on a web page is the Ctrl-F mechanism that every browser provides. However, this search mechanism provided by the browser is not sufficient. While blocks-based programming is visual, the browser's Ctrl-F search method is textual. Because of this, the browser's search mechanism presents several problems that illuminate why it is not sufficient. There are three specific problems users face with this default mechanism:
  1. Clearly Identifying the Searched Blocks - 

    After given a query, the browser's Ctrl-F search simply highlights the corresponding text in a yellow color. As users use the up and down arrow buttons to look through the matching text, the browser highlights the text in orange to notify the user which text they navigated to. While this may be sufficient when searching through a web page full of text, it is not sufficient for App Inventor. App Inventor is very colorful, so simply highlighting the text is too subtle to distinguish which blocks match the query given. Take, for example, a Wellesley College Computer Science Course, CS117, final project made by Sonali Sastry and Charlene Lee. Below, a user tries to use the browser's Ctrl-F search method to find any block with the matching query "checkIfList." As seen below, the highlight of the text is too subtle. 


  2. Centering and Highlighting Blocks - 

    After entering a query in the browser's Ctrl-F search method, users may use the up and down arrow buttons to navigate through the matching text. However, this mechanism only brings the user to the relative location of the text. The mechanism also has no interaction with the workspace, and so if a matching text is not seen within the Viewer, the browser will only scroll the web page down to indicate that the text is not within the Viewer. This may be disorienting and confusing to users of App Inventor. Using the same example as above, this problem can be witnessed in the video below. 


  3. Text Within Collapsed Blocks - 

    In App Inventor, the workspace is limited specifically to the Viewer. In order to save space on the workspace, some users collapse the blocks they are not looking at. However, in using the browser's Ctrl-F method to search, if there exists text on a block within a collapsed block that matches the query given, the text will not be shown or highlighted until the blocks are expanded. This could confuse users as they will not be able to determine which collapsed block contains the matching text. Using the same example as above, the video below demonstrates this problem.


These problems demonstrate why users are not able to properly utilize the default browser's Ctrl-F mechanism to search. Thus, App Inventor needs its own searching mechanism.
Improvements to Searching in App Inventor

As explained under the section, "Why Is Searching A Problem In App Inventor?", there are significant improvements that need to be made to the search ability in App Inventor. Cece's research dealt with implementing these improvements in App Inventor. 

Cece implemented App Inventor's very own Search Box, located at the top of the Viewer Box. This search box is similar to the browser's default Ctrl-F searching mechanism, though with several improvements made to correct the constraints and problems presented by the browser's search method. The improvements are three-fold:

  1. Clearly Identifying the Searched Blocks (Improvement) - 

    After given a query, the implemented search box will grey-out all irrelevant blocks, leaving the blocks that match the query in color. This clearly distinguishes which blocks match the search term, and thereby makes the searched blocks much more visible and apparent. Take, for example, a Wellesley College Computer Science Course, CS117, final project made by Sonali Sastry and Charlene Lee. Below, the video demonstrates how the greying out of the blocks works by searching for the phrase "checkIfList."



  2. Centering and Highlighting Blocks (Improvement) - 

    The implemented search box also allows users to use the arrow buttons and their arrow keys to navigate through the matching blocks. As a user navigates through the searched blocks, the block being looked at will be brought to the center of the viewer and outlined in a bright-pink highlight. This ensures that users are clear about what block they are currently looking at as well as orients the users. Using the same example as above, the improvement can be witnessed in the video below.


  3.  Dealing With Collapsed Blocks -

    The implemented search box will also handle collapsed blocks. If the top-level block of a collapsed block does not match the query given, but there exists a child block that does, the top-level block will still be colored to indicate that a child block exists within. In addition, when using the arrow buttons or keys to search through the matched blocks, if the block being looked at is within a collapsed block, the collapsed block will expand, and the block being looked at will be centered and highlighted accordingly. As the user continues to use the arrow keys and or buttons, the previously collapsed block will re-collapse. Users will thereby be able to better determine whether a collapsed block has a block that matches their query. Using the same example as above, the video below demonstrates this improvement.


The implementation of the Search Box thereby improves upon the constraints given by the browser's default Ctrl-F search mechanism. This work will continue to improve the search ability of App Inventor, and thus its user interface. See "Future Work & Research" for more information on what is next for the Search Box. 
Future Work & Research

Although the current implementation of the Search Box addresses the deficiencies presented by the browser's default Ctrl-F search method, the search box still needs work to continually improve. There are two aspects of future work in regards to the Search Box.
  1. Grey-Out All Parts of Irrelevant Blocks - 

    The Search Box intends to grey-out all of the block. However, in the way it is implemented now, certain icons and all parameter names are still colored. The colors may be distracting and confusing to users. As the research continues, the Search Box intends to ensure that all parts of the block are completely grey. The picture below, which uses the same example as the sections above, demonstrates this issue.




  2. Integrating Searching with Folders (Mini-Workspaces) -

    Shirley Lu and Devid Farinelli have worked on a new feature called folders. Folders are simply mini-workspaces that help to organize code. They are similar to collapsed blocks, but instead of being enclosed blocks, folders contain blocks. The picture below displays how folders work. Using the same example as above, the folder holds all procedure definitions. Thus, the folder called "procedureDefinitions" holds all code that is relevant to this name. Once minimized, the folder will collapse, and can be re-opened when needed. Future work in terms of searching and folders is the integration of these two features. The Search Box must be able to search within a folder and open the folder with the block in the center of the Viewer accordingly. 


These are currently two aspects of future work in regards to the Search Box. Though, the final goal is to ensure that the Search Box is successfully integrated into App Inventor.