Improved and simplified search box

[Anastasia Baryshnikova]

As discussed, instead of 2 search boxes, we could have only one and make it work as a filter. The attributes on which the filter would work for now are: all row labels and column labels. The search occurs by sequentially adding more and more filters based on the desired level of specificity. Filters also could be removed one at a time.

[Robert Leach]

This is a non-trivial task. We decided in a meeting to forego it for alpha03. The difficulty lies in implementing the GUI portions that select whether you're searching rows or columns (or even which type of label for each) and in representing and dismissing the applied search filters. E.g. Say you do a row search and then want an additional column search to find the combo. Where is the first search's dismissible filter? Currently, there's no space allocated in the interface to hold those filters.

[Robert Leach]

I mocked up a way to try to do this. I had the idea to implement the filters in a way using a JMenu that opens from a button next to the search field. (Ideally the button would be inside the search text box, but I don't think that's possible in swing.) The idea here is to mimic the way iTunes and other popular apps handle search options like this:

We already have a drop-down on the right which (when nothing is typed into the box) is a listing of all (in this case) row IDs, like this:

It may be disorienting to have a drop-down button on either side - so I'm open to suggestions which would address that. Perhaps a gear button with a dropdown mini icon to the right of the gear would be less confusing, but I chose to try to mimic iTunes in this mock-up:

As you can see, I decided to go with a checkmark to indicate which options/filters are active. We probably wouldn't be able to get it to look like this precisely, but the concept is the important part.

Users would be able to "check" "Row labels", which would have a default label type selected (e.g. the one that's currently visible next to the data). Probably be could default to both a row & column label search.

Whether row or column labels are checked (or both), that would determine how the other dropdown would be populated (whether it has row and/or column labels of the various types checked.

We would track the types of labels that have been previously selected. See how under "Column Labels" in my mock-up, the NAME label type has a gray checkmark? Even though the user is not searching column labels in this case, if they activate the column label search, it would already have NAME checked.

Under previous searches, we could probably keep track of say, 5 inactive previous searches (and all active previous search "filters"). So that has the potential of being a long list, so we would probably also utilize a scrollbar for this menu. All searches would be joined with "AND", so you wouldn't be able to look for search term 1 OR search term 2, though we could add another divider and put an "and" and "or" option.We would have to enforce that SOMETHING must be checked (rows or columns or whatever) to be a valid search - and at least 1 type underneath each category would have to be checked. Not sure how I would want to implement that behavior...

One thing I didn't add is that this menu could also provide options like "contains", "starts with", "ends with", etc.. We could even have a little info at the top of the menu that says something in gray italic, like:

* = multi-character wildcard ? = single-character wildcard

One last thing, you'll note I added the ability to search the values of the data. That's just a concept I wanted to include - I wouldn't want to tackle that at the same time as all the rest of this.

We might want some sort of safeguard to prevent invalid searches, like values that are less than -1 AND greater than 1.

Any thoughts @abarysh ?

[Anastasia Baryshnikova]

I like the general concept very much. A couple of thoughts:

1) Can you find a row/col combination using this method? E.g., row = 'abcd' & col = 'efghi'. It looks like you can't search 2 different things in 2 different fields, no? 2) I don't think we need to search values, I don't think that's a popular use case for Treeview. 3) What I had in mind was something a bit different. I'm attaching here a screenshot of the search function in Papers 3.0 (a software for organizing PDFs). It should be self explanatory, but the way it works is: you start typing, a window pops out to ask you where you want to search, then you press enter, you criteria is saved and you can add another one (search something else in a different field). When you are done, you press enter twice and the search starts. I don't know if that's possible in Treeview, but I just thought I'd show you.

[Robert Leach]

\1. Yes, combo row/col search is possible. The only catch is that with 1 search box (and with the fact that we have auto-complete using a JComboBox) you must do them 1 at a time and check the search in your previous searches (to search within those results). So you do a row search, select that search in your search options, and enter your column search.

Now that I imagine doing that, I'm not sure I like the idea. Unintuitive & cumbersome. Something with more immediately available visual cues would be more intuitive, like the example you gave. The difficulty is in merging the autocomplete with the filters. Autocomplete limits us to 1 term in the text field. Having filters with 'x's to dismiss them is limited by the space available in the interface. And using a menu to hold the filters would 1. overlap with the autocomplete menu and 2. probably not play well with autocomplete with the mouse clicking 1 or the other, changing the focus.

That said, I really like the search example you gave in #3. If we give up on autocomplete, it might make a floating popup like this containing filters possible, but we'd have to overcome the small size of the search box. Might not be possible in Swing, but might be worth a look.

Alternatively, if we can overcome confusion about the mouse changing focus, we could move the search options menu to be next to the autocomplete menu and have both dynamically appear side by side triggered by typing. It would have to contain both the previous search terms and the options. A menu would be the easiest thing to try. So it would look something like this:

If we do give up on autocomplete, I'm not sure if we could implement multiple search terms in 1 box or not - at least not in swing. Might be possible. I'd have to look into what's available.

\2. Yeah, I wasn't planning on doing a value search. I was just trying to come up with an example that was something other than row/col labels. However, if someone wanted to copy all the labels associated with elevated values, I could envision that being useful. Right now however, we don't support asymmetrical selections, so that's not even possible at the moment.

[Anastasia Baryshnikova]

I'm quite favorable to giving up on autocomplete, if necessary. I think other features (e.g., wild-card search + the possibility of extracting the selected rows/cols into a new matrix) will compensate for its absence and be just as intuitive.

[Christopher Keil]

Rob, such a floating menu could probably be nicely implemented using a context menu similar to the implementation of the current label view context menu (appears on right-click).

[Robert Leach]

Removing milestone: Search (automated comment)