QuickSearch Functionality for NetBeans IDE - UI and Functionality Proposal

Author: Ondrej Langr, xDesign Team
April & May, 2008

Table of Contents


Invokation of less frequently used actions (for which keybinding is not known by heart) frequently requires switching from keyboard to mouse which is a time-consuming and flow-breaking opeartion. The feature UI of which is mocked-up in this document would eliminate the need for frequent switching and thus helps the developer to remain in the state of flow.

Equivalent to this is using mnemonics or shortcuts, both of which have disadvantages this approach lacks, such as steep learning curve in case of shortcuts and difficulty to invoke actions with location of which the user is not sure in case of mnemonics.

Use Cases and Scenarios

This feature is a search in it's nature. There are too many use-cases to be named here, but most of them relate to finding something in the IDE.

Competitive Study

Applications using similar search

Applications using semantic command line paradigm or search.

Interesting features:


Among IDEs, no competitor with similar functionality was found.
! Update may 2008: Eclipse actually has similar feature hidden under Ctrl + 3 shortcut.


General Use-case Categories

In other words: what in the IDE makes sense to search for?


NEW: See the Flash storyboard ...

NOTE: due to the iterative development of this spec., the storyboard may not be reflecting this UI spec. entirely. Wherever there is a difference between this UI specification and the storyboard, this specification should take precedence)

Sections/Categories in the Search Results

Displaying Recent Searches

If this feature will be adopted not only as something which "searches" but also as something which "invokes" we can expect high level of repetitivness in searching. Therefore, items previously invoked should be present high in the search.

recent searches

This category should work as any other category, i.e. if there is no matching item, the category is not shown at all. Based on typical mid-term memory, the Recent Searches category should not contain more than about 4-6 items. This category would be the only category displayed before users start typing.

Keyboard Navigation

Quick and intuitive keyboard navigation is essential for usability of this feature. When user is typing, the currently active line in the dropdown should be highlighted (see images below). Following keys can be used:

Filtering the Search to a Single Category

By default, the search will provide results from all categories, as long as there is at least one match in each category. Those without any matching result will not be shown. Further, there will be two ways to filter the category to be searched. First, via a dropdown button:

chosen category         filter

In this case, the category to be searched should be shown in the textfield. If All Categories are chosen, the description inside the textfield should say "Search in NetBeans IDE".

Second option, faster and aimed at experienced users, is filtering categories by using an abbreviation of that category:

filtering to files only

Limiting the Number of Results

Typical use of similar (interactive) search functionality is such that a user types as long as they get a reasonable number of results. However, to prevent overwhelming the user with big number of results, we should limit the number of displayed results in each category to approximately 6-8 and allow the user to see all results if they specifically ask for it. Further, the search should never exceed the boundary of the screen.

Rules for limiting the number of displayed results:

Indication on Progress of Current Search

There are two main things to be indicated:

  1. There is still on-going search, i.e. there may be other results than displayed

    indication of search in progress

  2. The search has finished and no results are available

    no results

    no results while category filter is in use:
    no results while category filter is in use

Potential Problems

Context Sensitivity and Item Ordering - Still to be Discussed

Despite that search is fulltext, results where the match is in the beginning of the action name should be present first in the list. I.e., when searching for

Following paragraphs attempt to analyze the context in which actions work in order to prioritize and filter the offered actions to include only those which do make sense for users in the context they're in.

Examples of context sensitive situations:

Types of actions according to subject they work on

Classification according to where actions are exposed

Classification according to action state

Preliminary Conclusion on Ordering of Actions

Initial ordering of actions:

  1. Recently used actions (standalone category)
  2. Actions working in current window (selection in active editor, etc...)
  3. Actions working on current file
  4. Actions working on current project
  5. Actions working on other projects

Requirements to achieve the above:

Conflicting Action Names

How to deal with conflicting action names? Move on project VS Move in refactoring .. ?

Open Issues & Notes

Please ignore the following link: