openerp-community team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On 06/18/2014 07:01 PM, Oscar Alcala wrote:
>         The odoo team already did some improvements on the search Omnibox:
>         Inline image 2
>         This is a great feature, but I still think that can it can get better
>         it feels really weird clicking on a dropdown and suddenly seeing a
>         stripe appearing on the top of the list (maybe a search icon on the
>         header will make it more natural), dont get me wrong, current filtering
>         works fine and the Odoo team is focused in making thinks simple, a
>         single search box is a good choice for new users, this is because they
>         are not familiar with the UI, but what about users that know they
>         data?, users that already know the UI, these users need to focus on the
>         data itself, so using live filtering on text boxes on each column
>         header seems to me like a way to go.

Like all UX design choices, it is something naturally subjective, so I can only 
give you some hints.

As you know, the omnisearch allows you to do everything from a single place:
- filter using predefined filters (type the name of that filter)
- filter using custom filters (type the name of the custom filter)
- filter on fields that are not visible in the current (list/kanban/graph) view
- filter using smart filters that can execute arbitrary filter expressions, 
search on multiple columns at once, etc.
- craft complex filters with advanced search expressions (and save them as 
custom filters if needed)
- automatically combine filters with AND or OR operators as required
- toggle pre-defined group-by filters for data analysis
- etc.

This cannot be accomplished with multiple input fields on top of each column, 
so experienced users will definitely need to continue using the omnisearch.

But, even the basic "Search field for 'foo'" is just as fast with the 
omnisearch. You type "foo" and then use the arrow keys to select
   "Search Name for: foo"
or "Search Status for: foo".
Plus it will try to only auto-complete what makes sense, for example the 
suggestion for "Search Status" will only come up if what you typed matches a 
possible status.

Based on this, having extra search fields on each column seems like it would 
only clutter the interface without bringing any added value.

The main reported problem with the v7 omnisearch is that many2one fields are 
autocompleted using an automatic search in the data, which can slow down the 
autocompletion in some cases. So for v8 we'll make that search only on-demand, 
and the initial pop-up for suggestions will come up instantly all the time.

From our R&D point of view it seems better to improve the current omnisearch 
to make it efficient for both new and experienced users than to introduce more 
complexity/clutter in the interface.


>         I know it won't apply for all type of fields (Computed, Property and
>         Related), but what about having all fields searchable by default?, It
>         will make the module development process simpler, no need to declare
>         where I can or cannot search.

As listed above, a search view involves more than just being able to search 
each field with "field contains foo", so it is a good idea for the developer to 
think about it twice. We could think about pre-populating the search view with 
visible fields, but that would make the search view API hybrid and more 
complicated.