Search Wiki:

Future Focus: Searching and Navigating to Symbols

By Boris Jabes

Introduction

Welcome to another Future Focus post. The feature presented here is yet again language-agnostic and has already been popularized in other tools for a number of different programming languages. While it may be known under many names, we’ll refer to it as Search (nice and simple). The goal of the feature is to help users search for a symbol in their source code with a simple search box and a quick incremental result list. On the surface, designing this feature seems straightforward but there are a lot of open questions when trying to enable this for all the languages and users of VS. This post will highlight the user workflow and we’ll list out some interesting open issues where getting some user feedback would be very valuable.

Please enter your feedback on the symbol search feature here.

As always, it is important that readers of this post have the right expectations. The information presented here is not a binding commitment nor is it necessarily our most current design. The Visual Studio schedule, unforeseen technical problems, intellectual property rights and competitive pressures may impact our schedule or our ability to share our plans.
Future focus is not designed to present a detailed specification of future features. Instead, its purpose is to outline in broad strokes, and easy to understand terms, the directions the team will take in the future. I will report back to you on the impact of your comments, but please be patient, as it can take a long time for the team to make a final decision.

Search & Navigate

I like to think of this feature as having a primary and secondary goal. The first and foremost is to help users find & navigate to a specific location in their solution. Users find the location in question by typing a simple text string, getting a list of matching results, and selecting an entry. The elements we include in the search space are all symbols definitions and files in a solution. The secondary goal is to enable users to explore & navigate certain types of elements in their solution. The difference in this case is that the search string is not necessarily going to lead them to a unique entry and the utility of the feature is in its ability to pick a good set of matching results from a potentially vague query.
So what does this look like? Well, we haven’t ironed out the ideal user interface but the workflow looks something like this:
  1. User invokes Search shortcut
  2. Start typing search word(s)
  3. Results appear below and user can select with arrow keys
  4. Hit Enter and VS navigates to appropriate location

Mockup UI

symbol_search.jpg

The Search feature differs from the existing Find Symbol functionality in a number of ways:
    • It returns results incrementally
    • It does not support complex query strings (e.g. regular expressions)
    • It does not support iteration over a results
    • It is self-contained in a single dialog

Open Issues

Sorting & Ranking Results

We deal with multi-million line source bases, which span multiple projects, languages, platforms etc… There’s bound to be more than one item that matches the word “key” so how do we surface the right set in the best possible order? At this point we’re playing it safe and going with the longest matching prefix first. This doesn’t solve problems with symbols that have similar prefixes nor does it solve issues like preferring one language construct over another. Here are some ideas we’ve thought of and would welcome feedback.
  • Prioritize certain kinds of symbols (e.g. if I have C++ projects and C# projects, should C++ preprocessor macros come ahead of C# function names?)
  • Current file/project context (e.g. move symbols that are more closely related to the current editor context to the top of the list)
  • Allow user sorting of the results (i.e. given columns in our result list, one could potentially reorder based on type, full name, etc…)

User Interface

There is a lot of interest in the Search space across the industry today and is not restricted to code editing (Windows Vista provides ubiquitous searching from the Start menu). Just recently, the new version of the Firefox web browser introduced an enhanced URL bar dubbed “AwesomeBar.” It now tracks more data about each page in your history, which allows it to search and rank according to more criteria than just the prefix of the URL. They’ve also done some interesting work from a UI perspective to highlight matching substrings etc… The truth is, search is so popular today that there’s a lot of inspiration to go around. All in all, there’s a lot of ways we can build the UI and our main goal is to try and keep it simple yet efficient. Here’s some stuff we’ve bounced around.
  • Should we keep a history of recent searches?
  • Should we start with just a text box (similar to a URL bar or desktop search) and bring up searches once you type?
  • Should there be columns (with headers?)
  • To be modal or non-modal?
  • We want to make this a great keyboard-driven experience, so what are the best shortcuts (and navigation tricks) we can use?
  • Showing a preview of the location in source for the currently selected item
Tell us about your favorite and most hated ideas in this space! If you think there’s a tool out there that does an amazing job (doesn’t have to be in the IDE space), let us know as well.

Filtering Options

Once we’re past sorting and ranking comes the issue of filtering results. When there are a lot of results on the screen, a user may either
  • Not know which item to pick if the query is vague
  • Spend a lot of time foraging for a specific entry
    • Because it shares a name with so many others
    • Because the scope of the search is too wide
The second scenario is a great justification to enable filtering. If I’m looking for the field “foo” and the list is full of classes, macros, and files with the name “foo” then I’m going to waste valuable time. In addition, if I know the symbol is in my current project, shouldn’t I be able to ignore everything else at the flick of a switch? The more we look into these issues, the more we make the Search feature into a full-fledged Find Symbol replacement. So it’s a bit of a toss-up. On the one hand, we want to keep the user model and interface dead simple, but we also want to enable all VS users from beginner to guru. We’ve thought of a few ideas to integrate this idea.
  • Create a more advanced query language, which would have optional filtering operators (e.g. “<search word> -type:class”)
  • Add a single button on the dialog to jump to a few filtering options (the big issue here is how to deal with options specific to a language such as C++ preprocessor macros)
  • Add a checkbox to toggle the scope of the search (my solution vs. the entire set of included libraries)
  • Tabs to group certain kinds of results (e.g. files vs. symbols)

Everything Else

Feel free to send feedback on any other area of the feature that you think is important. This post was just a taste of the issues we’ve been looking at.
Please enter your feedback on the symbol search feature here.
Last edited Jul 11 2008 at 1:30 AM  by BorisJ, version 6
Updating...
Page view tracker