QuickSearch Functionality for NetBeans IDE - UI and Functionality Proposal
Author: Ondrej Langr, xDesign Team
April & May, 2008
Table of Contents
- Problem Description
- Use Cases and Scenarios
- Competitive Study
- Potential Problems
- Open Issues & Notes
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.
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.
Applications using similar search
- Spotlight on Mac OS
- Search in Thunderbird
Applications using semantic command line paradigm or search.
- Spotlight (macOS)
- QuickSilver (macOS, free)
- Enso (windows, free)
- Colibri (windows, free)
- Launchy (windows, free)
- Enso can quickly learn new commands (recorded macros?) by "learn identifier", and remove learnt or implicit by "unlearn identifier". Would something like this be applicable in our case?
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?
- option and settings
- what granularity? Just per panel or per settings?
- go to actions
- Go To Type
- Go To File
- windows (opening windows such as properties, output, debug, etc .. )
- (?) search in editor (Ctrl + F)
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)
- Recent Searches (see further description below)
- Projects/Files - Matching existing projects and files and also creating new projects/files
- Java Types
- Options & Settings
- Help & Documentation
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.
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.
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:
- Up and Down keys for moving the selection in the list
- Ctrl + Up, Ctrl + Down for navigation to next and previous category (Note: if search is limited to a single category, these keys should provide results for the next category even when the results are not yet in the list.)
- Page Up and Page Down - moving selection to the top/bottom of the results
- Enter for invoking currently selected item
- Esc - leaving the field, erasing the current selection and returning the focus in the IDE where it was before user switched to the quicksearch field. The default title "Search in NetBeans IDE" should be present in the field again (or appropriate if the search has been limited to a certain 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:
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:
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:
- If the search has been filtered to (or only returns items from) a single category, all available results should be displayed (unless they reach over the visible area)
- If there are results from several different categories and they can not fit into a reasonable area, indication that not all items are displayed in the list should look as displayed below. Upon selecting the "..." line, results should re-draw displaying all items, but only from the single category.
- For Java Types, the Go To Type dialog with the entered string and displayed results should be displayed upon selecting "..." (this is due to the fact that there can be way more types than we can display)
There are two main things to be indicated:
- There is still on-going search, i.e. there may be other results than displayed
- The search has finished and no results are available
no results while category filter is in use:
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:
- If focus is in editor, typing "fin" should offer the Find action at first whereas when focus is in projects window, Find in Projects should be offered instead.
- Action such as Go To Source should only be available when the cursor is located within an identifier this action can be invoked for.
- Checkout should probably offer first the checkout dialog for the versioning system user is using most often (Note: this particular use-case will be solved by the "recent searches" section)
Types of actions according to subject they work on
- Reformat, Refactoring, Move Line, Insert Code, Fix Imports ...
- May further divide to those available only in certain editors
- File (Run File, Reformat File ... )
- Actual open file with focus
- Selected File in Project window
- Project (Build Project, Run, Profile Project, Create New File... )
- Main Project
- Selected Project (selected in Project window or project the open file belongs to)
- Several Projects (Find in Projects, ... )
Classification according to where actions are exposed
- exposed directly via UI - in Menus (main, contextual)
- hidden - available only from a particular window (e.g. New Connection on Database Node in the Services Window)
- Should we only offer them in certain context
- combined (Add New Breakpoint is available in editor contextual menu as well as from Breakpoints window)
Classification according to action state
- Toggle actions - e.g. show line numbers. Are either on or off. Should this
- Repeatable actions - have the same results invoked several times
Initial ordering of actions:
- Recently used actions (standalone category)
- Actions working in current window (selection in active editor, etc...)
- Actions working on current file
- Actions working on current project
- Actions working on other projects
Requirements to achieve the above:
- meta-information for each action, including
- the context this action can be called from (editor - all textual editors or just language specific, projects window, etc...)
- specific name action used probably in this search only (this may be needed because in search result, the action lacks the context it is normally placed in. I.e. just the name of action Rename does not tell much about what it actually will rename).
- for dynamic ordering (frequently used actions are on top), we would need other persistant information - statistics on users' behavior
How to deal with conflicting action names? Move on project VS Move in refactoring .. ?
- Checkout (in CVS, in Subversion, in Mercurial, ... )
- How to deal with menu structure? Example: "Internationalization" matches what the user is typing, but it is a name of a submenu which contains other items. Possibilities:
- all the items in particular menu would have meta tagged their parent - all items in the Internationalization sub-menu would appear in results for "intern..."
open / expan
- Search by keybinding?
Please ignore the following link: lansky10