UIWG SearchUIAnalysis

Overview

A walkthrough of the Eclipse SDK was performed by Kevin McGuire in Sept/06 with a view towards consistency around wildcarding, filtering, and search.

Wildcarding

The treatment of wildcarding is often determined by search technology and performance characteristics. Thus it is unavoidable that different kinds of searches will treat wildcards differently; we cannot converge on a single solution. Some will use implicit wildcarding, some at end of string only, some not at all. Nevertheless some increased consistency is possible.

Filtering

We have a checkerboard strategy of supporting filtering. Its unlikely we want to tackle trying to bring together the different filtering approaches due to the scope of the work.

Search

We should consider a combined Search dialog and Search Result view. This would streamline user interaction and allow searches to be refined. We should also consider a non-modal approach to in-editor search (ala Firefox).

Search vs. "Find"

If you have a list with a lot of content you need to search the list itself. This isn't search in the workspace sense since you already have the items, you just need to get quickly to the one you want, or manage otherwise manage the size of the list.

<examples>

We can further refine this list into two categories:

1. You have a large list and you quickly want to get to the one you want. It assumes you know the name of what you want and you are just trying to avoid typing the whole name in. Lets call this "Find".
2. You have a large list and you need to reduce it down quickly to a few that match some textual criteria so that you can zero in on the one you want. This is more like "Search".

Where	Implicit wildcarding at start	Implicit wldcarding at end	Explicit wildcarding	Category
Open Type	no	yes	yes, + TZ	1 - Find
CVS History	yes	yes	no	2 - Search
Show View	yes	yes	yes	2 (1?)
Cntrl-O etc	no	yes	yes	2 - Search
Preferences	yes	yes	yes	2 - Search

For those in category (1), providing implicit wildcarding at the start of the string would actually take away from the optimized common work pattern. This is because the dialog always has the first item in the list selected, so the game is to keep typing until you've narrowed the list enough so the one you want is selected then hitting <return>. Adding implicit wildcarding generates "false hits" which changes the dynamics.

Recommend: For (1): Don't provide wildcarding at start, support implicit at end, support explicit. If we decide to add in-place filtering to other views, we should follow the same design.

For (2): Implicit wildcarding at start and end, support explicit.

Suggest: Identify additional views that would benefit from the list-reducing in-place search (2) like in CVS History (e.g. Problems View, Console).

Search flow issues

Search menu/dialog issues

1. Search action is in the main menu bar, but results appear in a view at bottom of screen. People are used to (from web searching) search and results being proximal in one browser/tab/whatever. The Help search facility is closer to this. Recommend: unified search parameters and results view (see below).
2. The tabbed dialog approach is confusing because only one tab is used. That is, usually tabbed dialogs use tabs to split the set of options across different real estate, but all the options combine. In our case, the pages are mutually exclusive and only the active one counts when you hit "Search". Recommend: (unified search view).
3. Every time you open the search you are back at File Search, or Java search if you have a Java element selected. While trying to refine a Plug-in search I repeatedly ran File Search by accident. Recommend: (unified search view).
4. Even though you might've picked Search->Java, you can in the resulting dialog do a File or PDE search by switching tabs. There needs to be a stronger correspondence between the menu item and the dialog behaviour. Recommend: (unified search view).
5. You cannot get the search dialog up from the search results view, so you cannot easily refine a search. You can "Re-run Search", but that just simply runs the same search again, which generally is not very useful. Recommend: (unified search view).
6. Because you cannot reopen the search dialog up again, you cannot see exactly what you searched for. You must interpret a dense single line description string that's printed in the search results view. This is difficult because (1) it generally only tells you the values you changed, not the defaults and (2) contents of the message is up to whoever implemented the method to create it so no automatic correspondance to the dialog settings (3) it doesn't "look" like the search I created. For example, this: <pic> yields this: <pic> and this: <pic> yields this: <pic>. Does "no JRE" mean an error, was it an option I picked (or didn't)? Recommend: (unified search view).
7. Its up to the individual search pane to remember the last usage. For example, File and Java searches remember the search strings, but Plug-in does not. Recommend: (unified search view) but not clear if API addition/changes needed.
8. You'd think that the drop-down where you type the Search string in would just give you the previous strings you typed in. Nope. Its actually a memory of *all* the search parameters. This is very misleading since its entry field represents only the search string (as labeled) and it remembering anything else is very non-standard. Recommend: (unified search view) but not clear if API addition/changes needed, plus will require some changes to existing dialog pages.
9. (minor) In the Views list we have both "Classic Search" and "Search". I've asked Dejan and he thinks we could probably get rid of Classic Search but would need to work with community to ensure nobody is still dependent on it. When you do a search, the results don't go to it, they go to the new Search view, so its of no more use. Recommend: remove Classic Search.

Search View issues

1. In its current form its actually a "Search Results" view, since you can't really do any searching from it. This could be confusing for new users who don't "get" that search is initiated from the Search menu or from specific menu actions in editors/views.
2. Further, it introduces some awkward user action sequences when he has to keep switching between the results and the menu bar to repeat/refine a search.
3. Some confusion may stem from a lack of ability to clearly represent though affordance the actual search performed. Here the view itself must represent both the last search results: <pic> as well as all previous searches: <pic> overloading the model for what the search view represents.
4. Multiple searches overwrite the view contents, requiring you to create a new view instance if you want to see two search results at the same time. The mechanism is pinning, which requires a degree of forethought on the part of the user that is perhaps unrealistic, especially since pinning is done in the view and searching is initiated elsewhere. Recommend: A more natural flow would be for new searches to be initiated in fresh/empty search views.
5. You learn that the results are cached, which is good because you'd like to avoid re-runnning them just to look at them. Its an odd notion of history though... what I need is first level affordance representing the searches I did (ie. its not history, its just view content). Its like saying that the editor list is history of what I've looked at. The result caching is of limited practical use since they do not listen for deltas and update. Recommend: A small number of search view instances, without history, would suffice.
6. Search view starts off in tree mode. You invariably want it in list mode sorted by path. In tree mode you don't easily spot the result, and there's just not enough space to work with the tree anyway. Recommend: results be presented in a list.
7. When you do a Java search, the search results now knows it was a Java search and grows Java tools and Java view menu items. This was surprising. For example: <pic> Recommend: nothing at this time, see next item.
8. If you open the Search View virgin, you get "Preferences". If you run a Plug-in search, you get no view menu at all! Recommend: not clear. On the one hand its just a bug, but it seems to suggest something very unnatural about the use of the view menu.

Places we can search

Where	Implicit Wildcarding	Explicit Wildcarding	* at start [3]
Help>Search : help doc	no	yes	no
Help>Search : Google	no	not really [1]	no
Help>Search : Eclipse	no	not really [1]	no
Search>File	no	yes	yes
Search>Java	no	yes	no
Search>Plug-in	yes [2]	yes	no

The first three searches (help, Google, Eclipse) are all federated in one interface in Help, which is powerful. However, as you can see not all federated search engines observe the same wildcarding rules. This means our current UI is misleading (because it claims that * and ? will do something) and makes it tricky to construct one search that works everywhere.

• [1] *'s seem to work only as separators between words. Google uses a full word index so you can't search "*ompare" and expect to find "compare".
• [2] you seem to get a free "*." at the start of your plugin name searches.
• [3] Some search technology cannot honour *'s at the start of the string, in particular Lucene. Yet another way a similar search in a different domain yields different results.

As a result of these differences, the user must understand the rules for wildcarding in each of these cases. This makes it tougher to learn how to search. Because these differences are driven by deep implementation differences in the search technology, we can't legislate one answer. It does increase the requirement for self-documenting search UIs.

Search View Proposal

We should consider a combined search parameters and results view, something like:

• The rich text Results area provides opportunity to show additional information with each hit. For example, the example above resulted in more than one hit in the same class, so they can be grouped underneath. The idea is to provide more context for the user so they can eliminate items they don't care about without opening editors on them (much as preview text helps for web browsing). This will help reduce number of editors people open, helping the problem of editor management.
• New search view instances can be created for different searches
• The main Search menu would result in a Search view of the "type" corresponding to the view menu.
• Must be a view (and not an editor) because need to be able to select result elements to drive selection in the editor

The search pages are looked up and for every control, a corresponding form control is created. Better results could be achieved with dedicated form control contributions but this shows that a form view approach can be achieved without requiring clients to recode.

• Q: How to identify one search from another based on tab?
• Issue: the only way I knew that PDE gave me a free *. at the start of the search was because the result status told me so. In this proposal we lose that status information, so user can't learn this about PDE.

Search vs. Filter

Some views, but not all, support filtering of the results. Although the filters are by definition domain specific and thus dialogs must be different, the general feel varies probably more than it should/could. I am not sure if we should consider trying to do anything here due to its scope. Even the consistency guidelines for this topic are going to be difficult to write.

<pics>

In Place Search (within Editor)

Eclipse has the aged modal dialog which obscures the very text you are trying to search.

Firefox grows a single line control area, non-modal, that does some (more common) of what the above does.

Should we make use of a similar single line search?

• We have more options
• We also need replace though, not sure how to factor it in.

(KM July 28/08: There was a GSoC project that prototyped this. I am told it is being looked at.)