[experimental] Change search panel to a single horizontal textbox

[yurishkuro]

It could be an alternative way of displaying search params for advanced users. The idea is that you just type things into the textbox and some intelli-sense helper provides auto-completion. E.g.:

service=hystrix tag:debug-id=myID time=last-30-min

[tiffon]

A couple of options around implementation:

• Code Mirror with autocomplete - Stays true to the text field input, not sure how well it handles very large lists of complete options, might have to limit to some sub-set (e.g. first 50 entries)
• VisualSearch.js - Deviates a bit from the text field input, also very dated, maybe makes sense to implement from scratch, but interesting prior art
• Select2 - A rock-solid dropdown component. Can be used, in series, to emulate the type of text field input you've described. Can be a bit nuanced to implement, but I've had some success with this approach in the past.
• From scratch with <div contenteditable>

Probably the best implementation of this feature, that I've seen, is the search input in the Smart Search feature of YouTrack.

[yurishkuro]

Yes, the YouTrack implementation looks very similar to what I had in mind. As long as the generic auto-completion component is implemented, the actual query syntax can be fairly straightforward to implement as a simple state machine.

[saminzadeh]

+1 I think this is a great idea.

Follow up question: Should this just be UI sugar, or is it better to have a query DSL on the backend that can interpret these queries?

[yurishkuro]

I think it should be just the UI feature. Because auto-complete is critical for such feature, it means the UI will already have a structured data model representing the query, not just a free form text, therefore there's no reason why the backend should be exposed to that.

BTW, to add a bit more, I think it would be useful to display already parsed / recognized tokens similar to how GitHub does it for labels:

[tiffon]

As a reference point, I took a look at the search interface in Facebook's ad management UI.

FB has taken a structured approach. This seems appropriate for complex search / filter functionality. As it stands, the Jaeger UI search is straight-forward, but if there are plans to make it more expressive then a similarly structured approach might be worth considering. Features like the following are simple in and of themselves, but they add up quickly if a number of them are included:

• Search on multiple services / operations at once via AND or OR
• AND two search queries together

Another aspect of the structured approach is discoverability for new users. This would only matter if the search functionality is made more expressive.

Some screenshots:

Top level attributes

Operators

Freeform text value input

Fully applied search clause

Multi-select search value input

Multiple values selected

Predefined filters

Date input

Date applied

Date range selection

Hints in the dropdown

[yurishkuro]

Overall I like it, but one thing I don't like is that it seems the filter cannot be entered (or removed) without using the mouse. The way I imagined this working in a textbox is similar to these screenshots, except the Add [+] happens automatically as you start typing something, and removing a filter can be done with a backspace (hit once - highlight the filter on the left, hit twice - delete it).

[tiffon]

IMO a UX along the lines of what you've described would be ideal. An example of the approach is the recipient entry in gmail, which also allows editing on `enter` in addition to deletion on `delete` or `backspace`. It should be possible to achieve it with a structured approach. It can be a bit tricky, but I've done it in the past with a filter implementation.

[Dieterbe]

I'd be curious to hear from @yurishkuro why advanced users would prefer this interface over the current interface (or potentially an improved version of the current interface, but with the same concept of a form of multiple fields). I suspect advanced users would prefer it if they don't like hitting tab to go from one form field to the next, especially skipping over form fields they don't need; and generally it's less distracting I think if they can do everything on the same horizontal line, instead of making your eyes jump all over a form.
So the main differentiator seems to me how we switch between /navigate across different filters/settings, but the editing experience of individual filters/settings can probably be made very similar between the two different UI approaches (not sure though)

Having provided a similar query input approach to users in the past (http://vimeo.github.io/graph-explorer) the feedback i constantly got is that new users wanted a very obvious way to be gently guided into all the searching/filtering possibilities. that said, my query input was nowhere near as helpful with autocompletions and widgets as yours is, but still the warning holds.
this of course raises the question about whether this will be an alternative/additional UI for power-users only (which doesn't need to be as beginner friendly), or the one and only interface (in which case we have to try really hard to make it intuitive and not put anything in the way hindering users who are unfamiliar with a lot of the concepts in trying to issue their first queries)

I generally like the concept though.
I like especially the first 2 pre-filled filters, but then it gets a tad confusing.
why does it first say "Search" but sometimes becomes "Tag, Min Duration ..." and back to "search" based on where you click? it gives the impression you can type an unstructured text seach query but that doesn't seem possible. (note that the current UI makes it very obvious what all the options are - probably because i'm still a fairly new user - i appreciate that a lot)
maybe it can set up the default state in such a way that it's more obvious what the possibilities are?
once i go past the first 2 widgets i get a bit confused about what I can and/or should enter.