[katello-devel] search tips, how to incorporate them into the GUI

[Brad Buckingham]

On 06/16/2011 03:43 AM, Amos Benari wrote:
> Hi,
> > From looking at the search related bugs I understand that part of the search syntax is not obvious.
> The reason I write this is to start a discussion on how to incorporate some of the tips into the GUI,
> or maybe get suggestions on how to make the syntax learning easy.
>
> Here is a short writeup on issues raised in the different bugs:
> 1. Case sensitivity.
>   When querying using '=' and '!=' the we are looking for an exact match, the match is case sensitive.
>   When running '~' (like) and '!~' (unlike) the match is case insensitive.
>
> 2. Using quotes.
>   In the search syntax white spaces are used as a delimiter.
>   Here are some examples of the way a query will be interpreted:
>    a. description ~ "created successfully"
>     =>  list all notifications that contains "created successfully"
>
>    b. description ~ created successfully
>     =>  list all notifications that contains "created"
>        and at least one of it's text fields contains "successfully"
>
>    c. description !~ created successfully
>     =>  list all notifications that doesn't contains "created"
>        and at least one of it's text fields contains "successfully"
>
>   In the second and third example "successfully" if an additional term that is
>   interpreted as a 'free text' search
>
> 3. Wildcard '_', '%' and '*'
>   The search terms are translated to SQL queries.
>   '~'  ->  LIKE
>   '!~' ->  NOT LIKE
>
>   LIKE statement supports two wildcards '_' and '%'.
>   a. '_' is a wildcard for a single character replacement.
>   For example the search "name ~ fo_" will match both 'foo' and 'for'.
>
>   b. The '%' and '*' wildcard will replace any number of characters including 0.
>   For example the search 'name ~ corp%' will match both 'corp' and 'corporation'.
>   The more common '*' wildcard is not an SQL wildcard but can be used in the search.
>
>   When the 'like' or 'unlike' search is processed, a '%' wildcard is added at the
>   beginning and the end of a value if it isn't there in the first place.
>
>   For example:
>   The search 'name ~ foo' will become "name LIKE '%foo%'"
>   The search 'name ~ foo%' will become "name LIKE 'foo%'"
>
>
> 4. Negation on a related field (maybe this can be an advanced topic)
>   When querying on 'environment.name = foo' in the organization page we are
>   looking for all the organization that has an environment that called 'foo'.
>   When we are looking for the complementary group of organizations we can issue
>   the following search 'not environment.name = foo'.
>
>   However when querying 'environment.name != foo' we will get a different result, a list
>   of all the organizations that has at least one environment that is not 'foo'.
>
> 5. Use parentheses when needed
>   parentheses are allowed in the syntax.
>
> Thanks,
>   Amos
>
>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
Hi Amos,

Good description of the syntax/behavior.  Thanks!

I think we have several possible options.  They could include (but 
aren't limited to):

1. use of an inline helptip (e.g. show/hide block of html), located near 
the search bar.  This is the approach that we use for helptips that are 
typically at the top of a page/panel to describe the page.

2. use of a helptip dialog (e.g. using jquery ui dialogs).  We don't 
have anything like this today for help; however, we have informally 
discussed supporting something like this in other cases (e.g. if needed 
help on a specific form field)

3. link to where the information is documented.  This would typically be 
to the actual product documentation.  We don't have this, yet; however, 
I've seen this approach used by other projects.

I'd probably lean towards 2; however, would like to hear what others 
think as well.

thanks,
Brad