Better search GUI
Cédric Krier
We know all that the current search interface is not perfect. It is easy for
simple query but not for complex one and the GUI takes a lot of space (even
without the advanced).
So we have thought about improving it. Here is some ideas and goals.
We think that users have their biggest experience in searching through the
Google webpage. Users know how it works and it is simple.
So we could apply the same mechanism to the Tryton search by having only one
long text entry. But we need some specific stuff like being able to specify
on which field the search must be done etc.
Here is some examples on how the syntax could be:
By default search is on rec_name
search: Holmes
domain: [('rec_name', 'ilike', '%Holmes%')]
By default many value are linked by AND
search: Holmes Watson
domain: ['AND',
('rec_name', 'ilike', '%Holmes%'),
('rec_name', 'ilike', '%Watson%'),
]
We can use OR operator
search: Holmes OR Watson
domain: ['OR',
('rec_name', 'ilike', '%Holmes%'),
('rec_name', 'ilike', '%Watson%'),
]
Quote to group words
search: "Sherlock Holmes"
domain: [('rec_name', 'ilike', '%Sherlock Holmes%')]
Append operator to use it
search: ="Sherlock Holmes"
domain: [('rec_name', '=', 'Sherlock Holmes')]
Use field name (label) to search on other fields
search: Code: 23
domain: [('code', 'ilike', '%23%')]
Selection fields are splitted into list
search: Language: Français English
domain: [('lang', 'in', ('fr_FR', 'en_US')]
Field name must be case insensitive
search: language: Français English
domain: [('lang', 'in', ('fr_FR', 'en_US')]
We can use internal field name
search: lang: Français English
domain: [('lang', 'in', ('fr_FR', 'en_US')]
We can use internal values
search: lang: fr_FR en_US
domain: [('lang', 'in', ('fr_FR', 'en_US')]
We can compose field search with by default AND
search: Name: Holmes Language: English
domain: [('name', 'ilike', '%Holmes%'), ('lang', '=', 'en_US')]
We can compose field search with OR
search: Name: Holmes OR Language: English
domain: ['OR', ('name', 'ilike', '%Holmes%'), ('lang', '=', 'en_US')]
But also have many values when composiing
search: Name: Holmes Watson Language: Français English
domain: ['AND',
['AND',
('name', 'ilike', '%Holmes%'),
('name', 'ilike', '%Watson%'),
],
('lang', 'in', ('fr_FR', 'en_US')),
]
User can also force how the wildcard are put
search: Name: Holmes*
domain: [('name', 'ilike', 'Holmes%')]
Parenthesis could be used
search: (Name: Holmes AND lang: Français) OR Name: Watson
domain: ['OR',
['AND',
('name', 'ilike', '%Holmes%'),
('lang', '=', 'fr_FR'),
],
('name', 'ilike', '%Watson%'),
]
Searching on amount
search: Payable: 1000
domain: [('payable', '=', 1000)]
search: Payable: >1000
domain: [('payable', '>', 1000)]
search: Payable: 500..1000
domain: ['AND', ('payable', '>', 500), ('payable', '<', 1000)]
And idem for dates
For boolean:
search: Active: false
domain: [('active', '=', False)]
Of course to be very ergonomic, the text entry will need autocompletion on
field names, validation of dates and numbers etc.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/
Udo Spallek
Am Donnerstag, den 11.02.2010, 21:03 +0100 schrieb Cédric Krier:
> Hi,
> We know all that the current search interface is not perfect. It is easy for
> simple query but not for complex one and the GUI takes a lot of space (even
> without the advanced).
Yes, thats true. But on the other hand the actual implementation is well known
by the users. So changing the ui in this place should be elaborate.
> So we have thought about improving it. Here is some ideas and goals.
> We think that users have their biggest experience in searching through the
> Google webpage. Users know how it works and it is simple.
Web search engines are widely used and known. Thats true. But they
provide all the way full text search functionality of documents. And
searching full-text is always more easy then searching in structured
data.
> So we could apply the same mechanism to the Tryton search by having only one
> long text entry. But we need some specific stuff like being able to specify
> on which field the search must be done etc.
> Here is some examples on how the syntax could be:
> By default search is on rec_name
First improvement: For me the default search should be full text in all
fields indicated by select="1" of a model.
> search: Holmes
> domain: [('rec_name', 'ilike', '%Holmes%')]
>
> By default many value are linked by AND
> search: Holmes Watson
> domain: ['AND',
> ('rec_name', 'ilike', '%Holmes%'),
> ('rec_name', 'ilike', '%Watson%'),
> ]
>
> We can use OR operator
> search: Holmes OR Watson
> domain: ['OR',
> ('rec_name', 'ilike', '%Holmes%'),
> ('rec_name', 'ilike', '%Watson%'),
> ]
>
> Quote to group words
> search: "Sherlock Holmes"
> domain: [('rec_name', 'ilike', '%Sherlock Holmes%')]
>
> Append operator to use it
> search: ="Sherlock Holmes"
> domain: [('rec_name', '=', 'Sherlock Holmes')]
So far so good. The above examples are widely standard imho
and easy to learn for newbies.
> Use field name (label) to search on other fields
> search: Code: 23
> domain: [('code', 'ilike', '%23%')]
Here it starts to get complicated. When we need to
explicitly state the fields to search it is getting
confusing and hard to maintain, if we have three or
more fields.
For a geek expert search your suggestions are quite good.
A user defined search which can be used without knowing
the exact syntax could be a simple domain builder like this*:
[ name | v ] [_______________] ( ) AND ( ) OR
|--------+
| name |
| code |
| amount |
L________|
* On the left selection you choose the model field.
* In the middle entry you put your search criteria
including all the functionalities you mentioned.
The middle entry can be a different widget for different
field types, like selection, list, float, date...
* Check an AND or OR radio button on the right side,
generates a new search line, like this:
[ name | v ] [Holmes_________] (o) AND ( ) OR [ DELETE ]
[ code | v ] [01234__________] ( ) AND ( ) OR [ DELETE ]
Using the radio buttons build a domain as you describe below with
parenthesis.
* When there is more then one line, a DELETE button appears
on all lines. When pressed, the appropriate line will be
deleted and the following lines move one line up, to fill
the gap.
* Even inline 'and' and 'or' are possible:
[ name | v ] [Holmes or Watson__] ( ) AND ( ) OR
> Selection fields are splitted into list
> search: Language: Français English
> domain: [('lang', 'in', ('fr_FR', 'en_US')]
Here I would suggest multi selection with modifier shift for
a range and ctrl for single entries.
For one2many and many2many I suggest a mapping of the related fields. So
we can search for specific addresses on party model.
> Of course to be very ergonomic, the text entry will need autocompletion on
> field names, validation of dates and numbers etc.
This all sounds very great. And I am sure I will use the new search
language every day. Users with a lesser affinity for 'programming' their
search domains will see a restriction by a singular entry box for
searches. This gap can be reduced with a domain composer and with a full
text search I suggested above.
For me all ideas having their benefit and weak. But all together, a
standard full text search with only one entry and an advanced search
with a field-wise domain-composer we can serve all the needs together.
Cheers Udo
(*) ASCII-arts are rendered readable with a monospace font.
Cédric Krier
> First improvement: For me the default search should be full text in all
> fields indicated by select="1" of a model.
Why not. But you can not do the same search on different kind of fields with
the same value. Per example string with float, etc.
By the way, using rec_name will extend the default behavior as it is already
done on many2one fields and many2many.
Of course this new syntax could be applied to those fields.
> For one2many and many2many I suggest a mapping of the related fields. So
> we can search for specific addresses on party model.
This is hard because the client don't know necessary the structure of the
relation field. But it could be a futher improvement.
>
> > Of course to be very ergonomic, the text entry will need autocompletion on
> > field names, validation of dates and numbers etc.
>
> This all sounds very great. And I am sure I will use the new search
> language every day. Users with a lesser affinity for 'programming' their
> search domains will see a restriction by a singular entry box for
> searches. This gap can be reduced with a domain composer and with a full
> text search I suggested above.
I find "domain composer" too complex, not ergonomic and take too much space.
I think what you try to achieve with the "domain composer" can be done on a
text entry with a good (smarter) autocompletion.
Here is a scenario:
Typing: n
Screen:
[n| ]
|-------
|Name |
|Number|
|... |
|------|
Select: Name
Screen:
[Name: | ]
Typing: Watson
Screen:
[Name: Watson | ]
Typing: c
Screen:
[Name: Watson c ]
|----|
|Code|
|... |
|----|
Select: Code
Screen:
[Name: Watson Code: | ]
Etc.
Autocompletion should work also on operators AND, OR
If a selection field is set: autocompletion must be also filled with selection
values.
And the convertion to domain should work even if missing closing )
>
> For me all ideas having their benefit and weak. But all together, a
> standard full text search with only one entry and an advanced search
> with a field-wise domain-composer we can serve all the needs together.
Yes but it is harder to maintain and I find merging the both into one will be
a big improvement. Because it could be used in many places (many2one,
many2many etc).
Udo Spallek
> On 12/02/10 12:32 +0100, Udo Spallek wrote:
> > First improvement: For me the default search should be full text in all
> > fields indicated by select="1" of a model.
>
> Why not. But you can not do the same search on different kind of fields with
> the same value. Per example string with float, etc.
in the input is text. Searching for 0.00 can search all float, numeric,
char and text fields.
> By the way, using rec_name will extend the default behavior as it is already
> done on many2one fields and many2many.
> Of course this new syntax could be applied to those fields.
> > For one2many and many2many I suggest a mapping of the related fields. So
> > we can search for specific addresses on party model.
> This is hard because the client don't know necessary the structure of the
> relation field. But it could be a futher improvement.
ok.
> > > Of course to be very ergonomic, the text entry will need autocompletion on
> > > field names, validation of dates and numbers etc.
> >
> > This all sounds very great. And I am sure I will use the new search
> > language every day. Users with a lesser affinity for 'programming' their
> > search domains will see a restriction by a singular entry box for
> > searches. This gap can be reduced with a domain composer and with a full
> > text search I suggested above.
> I find "domain composer" too complex, not ergonomic and take too much space.
I'm unsure if learning a search grammer is less complex then using a
domain composer with good restrictions on input level. The same with the
ergonomic reasons: If you like to 'code' your search domain, it is more
ergonomic. If not, it is much more ergonomic to use a simple self
explanatory domain builder instead of reading documentation to just
start a search.
Space for the standard search with a domain builder is the same as your
proposal. Just a single line. for each AND, OR it is one line more.
Yes, I am sure it can be fault tolerant in some way and with a good auto
completion for fields and logical operators.
IMHO the biggest issue in your proposal is, that the valid check for
field operands will be done after hitting the search button. On input
seems everything possible, because everything can be a search string.
E.g. what would be the solution for a search like this:
'''Comment: and as Watson said loud at the very beginning
of the party: Holmes, Reputation is made in a moment: It takes a
lifetime to build character.'''
In this string are several problems to evaluate, because you can not
decide what is search grammer and what is its context.
In the actual implementation the check is a restriction on input time,
which I find much better, because you need no error messages like: 'A
date field must look like dd/mm/yyyy'. Now an input field for a date is:
__/__/____ [] with a nifty popup calendar button on the side. Other
example is, we can not put the string 'hello world' in a field numeric,
because only numbers, minus and a separator are allowed for input.
The actual implementation has also a good restriction of operators for
the different fields. Not to say that we have named operators like
starts with, contain, end with...
Will this all be lost? For me all the stuff we have is the half way to a
domain composer.
> > For me all ideas having their benefit and weak. But all together, a
> > standard full text search with only one entry and an advanced search
> > with a field-wise domain-composer we can serve all the needs together.
> Yes but it is harder to maintain
I'm not sure if it is harder to maintain, because a lot of concepts from
the actual implementation can be reused.
Cédric Krier
> Am Freitag, den 12.02.2010, 12:29 +0100 schrieb Cédric Krier:
> > On 12/02/10 12:32 +0100, Udo Spallek wrote:
> > > First improvement: For me the default search should be full text in all
> > > fields indicated by select="1" of a model.
> >
> > Why not. But you can not do the same search on different kind of fields with
> > the same value. Per example string with float, etc.
> Hmm, but you suggested that the field is a text entry box. So everything
> in the input is text. Searching for 0.00 can search all float, numeric,
> char and text fields.
No, you can not search on a float with a string.
> > > > Of course to be very ergonomic, the text entry will need autocompletion on
> > > > field names, validation of dates and numbers etc.
> > >
> > > This all sounds very great. And I am sure I will use the new search
> > > language every day. Users with a lesser affinity for 'programming' their
> > > search domains will see a restriction by a singular entry box for
> > > searches. This gap can be reduced with a domain composer and with a full
> > > text search I suggested above.
> > I find "domain composer" too complex, not ergonomic and take too much space.
> I'm unsure if learning a search grammer is less complex then using a
> domain composer with good restrictions on input level. The same with the
> ergonomic reasons: If you like to 'code' your search domain, it is more
> ergonomic. If not, it is much more ergonomic to use a simple self
> explanatory domain builder instead of reading documentation to just
> start a search.
> Space for the standard search with a domain builder is the same as your
> proposal. Just a single line. for each AND, OR it is one line more.
I think you don't see the complexity of a domain builder like you describe.
Because once you have AND and OR operator, you must have parenthesis and at
this point this become complex (for the code and for the interface).
I think we can find a grammar that doesn't need to be learn because of the
simplicity and the help of autocompletion etc.
> IMHO the biggest issue in your proposal is, that the valid check for
> field operands will be done after hitting the search button. On input
It could have some typing check (like on date and number fields).
> seems everything possible, because everything can be a search string.
> E.g. what would be the solution for a search like this:
> '''Comment: and as Watson said loud at the very beginning
> of the party: Holmes, Reputation is made in a moment: It takes a
> lifetime to build character.'''
>
> In this string are several problems to evaluate, because you can not
> decide what is search grammer and what is its context.
You can because we know the name of the fields. So if a string that ends with
a ":" matches the name of a field, it is a search on a field.
>
> In the actual implementation the check is a restriction on input time,
> which I find much better, because you need no error messages like: 'A
> date field must look like dd/mm/yyyy'. Now an input field for a date is:
> __/__/____ [] with a nifty popup calendar button on the side. Other
> example is, we can not put the string 'hello world' in a field numeric,
> because only numbers, minus and a separator are allowed for input.
We can acheive that.
>
> The actual implementation has also a good restriction of operators for
> the different fields. Not to say that we have named operators like
> starts with, contain, end with...
>
> Will this all be lost? For me all the stuff we have is the half way to a
> domain composer.
I think it is an end way. Most of the search are really simple and so a domain
composer will be use very rarely.
Mathias Behrle
+0100):
> Will this all be lost? For me all the stuff we have is the half way to a
> domain composer.
Just as a short input:
In QT it is (or can be) done like this:
you can have a switch view for
- either viewing the record list
- or for viewing the search window with all fields of current object listed
with their relative suitable input options
This way the 'domain builder' takes just an icon resp. a shortcut and switches
completely between the two views.
Of course I can provide an image if it is of interest.
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://mbsolutions.selfip.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x89BCA161
Hartmut Goebel
a fried pointed me to Trackworld which implements a sophisticated search
interface. Screenshots are available in the user manual
<http://www.belox.de/downloads/software/tw5/manual/Anwenderhandbuch.pdf>
on pages 38 ff. Trackworld allows saving searches and views.
A demo is available, too. See
<http://www.belox.de/form_download_demo.html> AFAIK the software is not
localized and only available in German.
--
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP
Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de
Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult mit Mitglied bei http://www.7-it.de
Timitos
OK. I needed to think a bit about this topic.
I see two different interests here. On the one hand we need an easy
search gui
for fast search that does not consume space in the gui. On the other
hand there
seem to be a need for somethink like a domain builder or a user
friendly search tool.
I think on the long run both would be great as for some users a user
friendly domain
builder would be easier to user (perhaps).
But i also think that the suggested easy search field of cedric would
be for me a good
improvement for now. So it would be great if you could do this cedric.
But the new solution
should not lose comfort for the user compared to the actual one.
If there is later a big interest for a domain builder: yes lets do
that too. But lets do that later.
Korbinian
Cédric Krier
> But i also think that the suggested easy search field of cedric would
> be for me a good
> improvement for now. So it would be great if you could do this cedric.
> But the new solution
> should not lose comfort for the user compared to the actual one.
A good example of what we thought is the addresse bar of Chromium.
If you start typing google.com and press tab, you will have a box containing
"Search Google:".
>
> If there is later a big interest for a domain builder: yes lets do
> that too. But lets do that later.
I think both can be in the same widget. Because if you can use a domain
builder with AND and OR operator, you will understand a simple syntax with
parenthis and logical operator.
Chenal Bertrand
I have started to work on this topic but I'm stuck. First what's working :
I have uploaded two files on codereview[1]:
- completion.py (needs python 2.6): is able to handle search strings
like "first name:john" or "description:test status:draft" and propose
auto-completion, I.E: for "first na" it will suggest "First Name:". But
it doesn't understand operators parenthesis, etc.
- parse.py (use pyparsing): is able to handle parenthesis, and, or, and
quotes but it does not work when a field contains two words. IE
"State:draft and Amount:100" will work, but "first name:John" not. Also
'state:draft and "first name:John" ' is ok.
So the goal is to makes those two small codes works together. IMO the
biggest challenge is to define a grammar in pyparsing that will parse
something like "word AND more than one word OR etc" instead of only
single words between operators. Does someone know if pyparsing is able
to do this ?
Cheers,
Bertrand
[1] http://codereview.appspot.com/2099045
--
Bertrand Chenal
B2CK SPRL
Rue de Rotterdam, 4
4000 Li�ge
Belgium
Tel: +32 474 207 906
Email: bertran...@b2ck.com
Website: http://www.b2ck.com/
Bertrand Chenal
Hi,
Just to inform that I have added a small gtk example that allow to see
it in action: http://codereview.appspot.com/2099045.
To get the files, dowload the raw patch set, then use the patch command
like: "patch -p0 < issue_xx.diff" this will create a directory "b" with
the sources in it. To see the demo just launch gtk_demo.py.
This demo just handles simple domains (not parenthesis no AND / OR).
Cheers,
Bertrand
Le Thu, 09 Sep 2010 22:37:56 +0200,
Chenal Bertrand <b...@b2ck.com> a écrit :
Mathias Behrle
+0200):
Hi Bertrand,
> Just to inform that I have added a small gtk example that allow to see
> it in action: http://codereview.appspot.com/2099045.
>
> To get the files, dowload the raw patch set, then use the patch command
> like: "patch -p0 < issue_xx.diff" this will create a directory "b" with
> the sources in it. To see the demo just launch gtk_demo.py.
>
> This demo just handles simple domains (not parenthesis no AND / OR).
The gtk_demo needs query_parser. Can you say how to get it?
Thanks,
Mathias
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
Bertrand Chenal
Mathias Behrle <math...@mbsolutions.selfip.biz> a écrit :
> * Betr.: " Re: [tryton-dev] Better search GUI" (Wed, 29 Sep 2010
> 16:38:20 +0200):
>
> Hi Bertrand,
>
> > Just to inform that I have added a small gtk example that allow to
> > see it in action: http://codereview.appspot.com/2099045.
> >
> > To get the files, dowload the raw patch set, then use the patch
> > command like: "patch -p0 < issue_xx.diff" this will create a
> > directory "b" with the sources in it. To see the demo just launch
> > gtk_demo.py.
> >
> > This demo just handles simple domains (not parenthesis no AND / OR).
>
> The gtk_demo needs query_parser. Can you say how to get it?
It was an error, I updated the issue.
> Thanks,
> Mathias
>
>
--
Bertrand Chenal
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Mathias Behrle
+0200):
> Just to inform that I have added a small gtk example that allow to see
> it in action: http://codereview.appspot.com/2099045.
>
> To get the files, dowload the raw patch set, then use the patch command
> like: "patch -p0 < issue_xx.diff" this will create a directory "b" with
> the sources in it. To see the demo just launch gtk_demo.py.
>
> This demo just handles simple domains (not parenthesis no AND / OR).
Thanks for this first plot looking promising, while I am not able to contribute
anything to the pyparsing problem, sorry.
Nevertheless for me some principal questions of this thread are not yet
answered:
1) Will we lose the actual search interface, if the 'one-line-search' will be
implemented?
- At first simplicity for the user will be lost, because he has to learn, that
specification of fields has to be done in the one-liner. While this could be
a rather simple learning step the search over several fields will afford to
learn the syntax needed. Could be too straightforward for the scope of many
users IMO.
If a user has minimal understanding of logical operators it is a very
smart solution, but I am pessimistic in this respect.
2) Will we lose all those differentiated operators like 'Begins with', 'Is'.
etc.?
The ideal solution for me would be to have this one-liner-interface (provided
it can be done in a sufficient sophisticated way) on top of the form with all
other search fields (the well known search interface until now) collapsed. If
the search fields could be shown (extended) with a click on an arrow just
besides the one-liner-interface all users could have their prefered interface.
Cédric Krier
> * Betr.: " Re: [tryton-dev] Better search GUI" (Wed, 29 Sep 2010 16:38:20
> +0200):
>
> > Just to inform that I have added a small gtk example that allow to see
> > it in action: http://codereview.appspot.com/2099045.
> >
> > To get the files, dowload the raw patch set, then use the patch command
> > like: "patch -p0 < issue_xx.diff" this will create a directory "b" with
> > the sources in it. To see the demo just launch gtk_demo.py.
> >
> > This demo just handles simple domains (not parenthesis no AND / OR).
>
> Thanks for this first plot looking promising, while I am not able to contribute
> anything to the pyparsing problem, sorry.
>
> Nevertheless for me some principal questions of this thread are not yet
> answered:
>
> 1) Will we lose the actual search interface, if the 'one-line-search' will be
> implemented?
>
> - At first simplicity for the user will be lost, because he has to learn, that
> specification of fields has to be done in the one-liner. While this could be
> a rather simple learning step the search over several fields will afford to
> learn the syntax needed. Could be too straightforward for the scope of many
> users IMO.
> If a user has minimal understanding of logical operators it is a very
> smart solution, but I am pessimistic in this respect.
I think now almost every body can use google. And we tried to be as closest as
possible of this scheme by having implicite AND, automatic quote etc.
>
> 2) Will we lose all those differentiated operators like 'Begins with', 'Is'.
> etc.?
>
> The ideal solution for me would be to have this one-liner-interface (provided
> it can be done in a sufficient sophisticated way) on top of the form with all
> other search fields (the well known search interface until now) collapsed. If
> the search fields could be shown (extended) with a click on an arrow just
> besides the one-liner-interface all users could have their prefered interface.
The goals is to get rid of the current search view because it is not powerfull
enough, it takes too much place and it is hard to extend it (like having full
text search).
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
Mathias Behrle
+0200):
> On 30/09/10 13:03 +0200, Mathias Behrle wrote:
> > * Betr.: " Re: [tryton-dev] Better search GUI" (Wed, 29 Sep 2010 16:38:20
> > +0200):
> > Thanks for this first plot looking promising, while I am not able to
> > contribute anything to the pyparsing problem, sorry.
> >
> > Nevertheless for me some principal questions of this thread are not yet
> > answered:
> >
> > 1) Will we lose the actual search interface, if the 'one-line-search' will
> > be implemented?
> >
> > - At first simplicity for the user will be lost, because he has to learn,
> > that specification of fields has to be done in the one-liner. While this
> > could be a rather simple learning step the search over several fields will
> > afford to learn the syntax needed. Could be too straightforward for the
> > scope of many users IMO.
> > If a user has minimal understanding of logical operators it is a very
> > smart solution, but I am pessimistic in this respect.
>
> I think now almost every body can use google. And we tried to be as closest as
> possible of this scheme by having implicite AND, automatic quote etc.
BTW I am rather surprised by the fact that there exist people not being able to
use google. Probably not our target user group, which should be instructed to
enter correct data in an ERP...
OTOH exactly google has the design I am promoting:
Simple search on one line combined with Advanced search providing a more
detailed interface.
> > 2) Will we lose all those differentiated operators like 'Begins with', 'Is'.
> > etc.?
> >
> > The ideal solution for me would be to have this one-liner-interface
> > (provided it can be done in a sufficient sophisticated way) on top of the
> > form with all other search fields (the well known search interface until
> > now) collapsed. If the search fields could be shown (extended) with a click
> > on an arrow just besides the one-liner-interface all users could have their
> > prefered interface.
>
> The goals is to get rid of the current search view because it is not powerfull
> enough, it takes too much place and it is hard to extend it (like having full
> text search).
The current proposal loses some differentiated operators, so it is less
powerful. It wouldn't take any place if being collapsed at first sight. Full
text search could be only for the one-liner.
Sticking to my proposal as indeed google referenced by you does it exactly this
way.
Cédric Krier
This advanced search is less powerfull that the default google one.
>
> > > 2) Will we lose all those differentiated operators like 'Begins with', 'Is'.
> > > etc.?
> > >
> > > The ideal solution for me would be to have this one-liner-interface
> > > (provided it can be done in a sufficient sophisticated way) on top of the
> > > form with all other search fields (the well known search interface until
> > > now) collapsed. If the search fields could be shown (extended) with a click
> > > on an arrow just besides the one-liner-interface all users could have their
> > > prefered interface.
> >
> > The goals is to get rid of the current search view because it is not powerfull
> > enough, it takes too much place and it is hard to extend it (like having full
> > text search).
>
> The current proposal loses some differentiated operators, so it is less
> powerful. It wouldn't take any place if being collapsed at first sight. Full
> text search could be only for the one-liner.
There will not be less operators. Every operators in trytond will be available
which means there will be more operators. In fact I readed the code and
Bertrand did not follow what we talked. He uses only "ilike" operators but
this must be only the default one and operators could be define after the
field.
Mathias Behrle
+0200):
To be demonstrated. At least filtering by date opens a useful sidebar.
> > > > 2) Will we lose all those differentiated operators like 'Begins with',
> > > > 'Is'. etc.?
> > > >
> > > > The ideal solution for me would be to have this one-liner-interface
> > > > (provided it can be done in a sufficient sophisticated way) on top of
> > > > the form with all other search fields (the well known search interface
> > > > until now) collapsed. If the search fields could be shown (extended)
> > > > with a click on an arrow just besides the one-liner-interface all users
> > > > could have their prefered interface.
> > >
> > > The goals is to get rid of the current search view because it is not
> > > powerfull enough, it takes too much place and it is hard to extend it
> > > (like having full text search).
> >
> > The current proposal loses some differentiated operators, so it is less
> > powerful. It wouldn't take any place if being collapsed at first sight. Full
> > text search could be only for the one-liner.
>
> There will not be less operators. Every operators in trytond will be available
> which means there will be more operators.
Of which operators are you talking? Those of
http://doc.tryton.org/1.6/trytond/doc/topics/domain.html?
Those don't contain operators like 'start with', 'end with'.
> In fact I readed the code and
> Bertrand did not follow what we talked. He uses only "ilike" operators but
> this must be only the default one and operators could be define after the
> field.
Ok, sounds much better to me, but I still don't know, how you would want to
name those operators e.g. 'start with' or 'end with'. It will be difficult to
find intuitive descriptors while keeping simplicity for the user. Perhaps a
list of possible operators could open via completion after inserting a field?
Phillip Heller
Specifically, I think it would be useful to show a model's form representation, which a user could populate with values. Perhaps this search "form" could have right-click context menu options to alter the field from a default of "like" to "not like", etc.
This would be reminiscent of the Informix 4GL UI, which was very convenient.
Thoughts?
Regards,
Phil
Cédric Krier
> > > > > 2) Will we lose all those differentiated operators like 'Begins with',
> > > > > 'Is'. etc.?
> > > > >
> > > > > The ideal solution for me would be to have this one-liner-interface
> > > > > (provided it can be done in a sufficient sophisticated way) on top of
> > > > > the form with all other search fields (the well known search interface
> > > > > until now) collapsed. If the search fields could be shown (extended)
> > > > > with a click on an arrow just besides the one-liner-interface all users
> > > > > could have their prefered interface.
> > > >
> > > > The goals is to get rid of the current search view because it is not
> > > > powerfull enough, it takes too much place and it is hard to extend it
> > > > (like having full text search).
> > >
> > > The current proposal loses some differentiated operators, so it is less
> > > powerful. It wouldn't take any place if being collapsed at first sight. Full
> > > text search could be only for the one-liner.
> >
> > There will not be less operators. Every operators in trytond will be available
> > which means there will be more operators.
>
> Of which operators are you talking? Those of
> http://doc.tryton.org/1.6/trytond/doc/topics/domain.html?
> Those don't contain operators like 'start with', 'end with'.
'start with' = ilike '...%'
'end with'= ilike '%...'
>
> > In fact I readed the code and
> > Bertrand did not follow what we talked. He uses only "ilike" operators but
> > this must be only the default one and operators could be define after the
> > field.
>
> Ok, sounds much better to me, but I still don't know, how you would want to
> name those operators e.g. 'start with' or 'end with'. It will be difficult to
> find intuitive descriptors while keeping simplicity for the user. Perhaps a
> list of possible operators could open via completion after inserting a field?
Most of operators are simple =, <, > etc.
ilike is the default
in will be the default when the value is a list
child_of will need to be defined (but I'm not sure it is useful in UI).
Bertrand Chenal
Cédric Krier <cedric...@b2ck.com> a écrit :
I don't think operators are a difficult problem (at least technically).
The biggest obstacle a the moment is to handle correctly the mix of
AND/OR and parenthesis while allowing also the user to not put them
(I.E. search like "field:value other field: other value").
--
Bertrand Chenal
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Ian Wilson
Would it be acceptable to change this case from:
search: lang: fr_FR en_US
domain: [('lang', 'in', ('fr_FR', 'en_US')]
domain: [('lang', 'in', ('fr_FR', 'en_US')]
I think the user will have to quote anything that contains spaces for both field names or field values.
field:value other field: other value
field:value 'other field': 'other value'
-Ian
Also I think have in be configurable for this type of thing
Bertrand Chenal
Ian Wilson <vengful...@gmail.com> a écrit :
> Is work still being done on this ? I have some ideas and I prototyped
> some code.
>
> Would it be acceptable to change this case from:
>
> search: lang: fr_FR en_US
> domain: [('lang', 'in', ('fr_FR', 'en_US')]
>
> search: lang: fr_FR, en_US
> domain: [('lang', 'in', ('fr_FR', 'en_US')]
>
> I have added a comma between values so that lists of values can be
> distinguished from implicit search against rec_name. I think this
> will make it easier for the user to enter searches otherwise implicit
> search against rec_name must be done strictly before any of these
> types of searches. Also I think this would make the implementation
> less complicated.
>
> I think the user will have to quote anything that contains spaces for
> both field names or field values.
> field:value other field: other value
>
> So this must be like this:
> field:value 'other field': 'other value'
>
> -Ian
Hi,
I made some progress on this front: I dropped the idea of using
pyparsing and similar bns-inspired libraries, they are too difficult to
use in this case. After some search I discovered top-down parsing[1],
which is a simple algorithm, easy to tweak and it gives good results.
To answer some of your questions:
- I also think it's better to put comma for the right members of an IN
clause. Without them it's impossible to understand stuffs like :
Name: Julian Paul Assange Eric Daniel Pierre Cantona
While
Name: Julian Paul Assange, Eric Daniel Pierre Cantona
is far more clear (example inspired by Google news). Comma may not be
necessary when we know all the possible values like:
State: Open Close
But I'm in favor of considering the comma mandatory for 'in' clause,
even with well-known values.
- Quotes should be optional, for example:
Name: John Doe Company:Acme
is understandable. But,
King: Henry the First Name:Alfred
(let's say we have a table with a field King, a field Name and a
field First Name) in this case quotes are needed around "Henry
the First" or around "First name" to remove all ambiguity.
In my implementation I favor the longest match on field name (so
implicit "First Name" in this example).
The code is uploaded on codereview[2], but is not complete yet,
currently missing:
- ">" and "<"
- Negation: something like "Name: !John" or "!State: Draft, Confirmed".
- Tweak domain creation wrt to the type of field, for example:
Name: True
should give a different domain that
Active:True
(and maybe "Active: Yes" would be better).
Also:
Parent: Main category
creates something like [('parent', 'ilike', 'Main Category')], which
is not ok.
- Auto-completion only works on fields name, it would be great to also
have it when we know which values are availables (on Bollean and
Selections)
- I also think about stuffs like "Name: Bell*"
- Probably more :)
I propose to keep high-level discussion on this list and remarks about
code details on the codereview.
[1] http://effbot.org/zone/simple-top-down-parsing.htm
[2] http://codereview.appspot.com/3536042 -> if you run it, it will
output for each item of a list of examples: a tree resulting of the
parsing, one or more auto-completion (if possible) and a domain.
Ian Wilson
It seems that autocomplete will be hard unless we move the : to the front of the field name. How will you know to auto complete a field instead of some sort of value? Won't auto complete for names coming up when you are entering values be intrusive?
--
tryto...@googlegroups.com mailing list
Ian Wilson
http://codereview.appspot.com/3546042/
The basic format is:
'field name': operator? 'field value'
* Tryton operators with spaces must use -. For example not in must be not-in.
* Both field name and operator are not required.
* If operator is a symbol then ? is not necessary.
* The field value can be values separated with commas, such as "state: in? draft, done"
* Quoting must be done with single quote only and is only required when there are spaces or ambiguous symbols in the token.
* Does not support custom % placement in *like operators.
I think for autocompletion to work we must have field names start with ":" and in a similar way we could have operators start with ?. Such as :rec_name ?ilike Ian.
-Ian
Bertrand Chenal
Hi,
I have put my work on a mq repository:
http://www.b2ck.com/~bch/hg/tryton_tdp/
Current state:
- Should be feature-complete wrt to auto-completion and domain
generation. All field type are not supported: text, boolean and m2o
should work, selections needs some work.
- Integration with the gtk client is still sketchy: the entry box
should be placed between the "search" label and the other buttons
("prev", "next", "search" and "clear"), limit and offset should be
hidden (IMO removed). Maybe more user feedback is needed to tell him
if the current query is valid, a tooltip, etc. + some code cleaning
(for all the old search widgets) is needed.
Screenshot: http://i.imgur.com/dW6sC.png
Examples:
Test
-> Trigger search on rec_name for "Test"
Name: Test
-> Generates: name ilike 'Test%'
Name: =Test
-> name = 'test'
Name: ~Test
-> name != 'Test'
Code: 3..6
-> code >=3 and code <6
Code: >3
-> code > 3
Code: 2,4,5
-> Code in (2,4,5)
All of those may be combined with "and", "or", "(", ")" and with
quotes (to tell the parser not to interpret the inner content), ex:
Name: "Test" or (Code: 2 and Language: English)
How to apply the patch:
cd /path/to/tryton
hg clone http://www.b2ck.com/~bch/hg/tryton_tdp/ .hg/patches
hg qpush
OR
cd /path/to/tryton
wget http://www.b2ck.com/~bch/hg/tryton_tdp/raw-file/tip/tdp -Otdp.patch
patch -p1 < tdp.patch
There should be a one-liner to apply the patch with hg import, but I
didn't succeed, does someone know how to do it ?
Bertrand
Cédric Krier
> cd /path/to/tryton
> wget http://www.b2ck.com/~bch/hg/tryton_tdp/raw-file/tip/tdp -Otdp.patch
> patch -p1 < tdp.patch
>
> There should be a one-liner to apply the patch with hg import, but I
> didn't succeed, does someone know how to do it ?
hg import --no-commit http://www.b2ck.com/~bch/hg/tryton_tdp/raw-file/tip/tdp
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Cédric Krier
> Hi,
>
> We know all that the current search interface is not perfect. It is easy for
> simple query but not for complex one and the GUI takes a lot of space (even
> without the advanced).
Finally, it is pushed in trunk.
Luis Falcon
On 11/02/10 21:03 +0100, Cédric Krier wrote:
> Hi,
>
> We know all that the current search interface is not perfect. It is easy for
> simple query but not for complex one and the GUI takes a lot of space (even
> without the advanced).
Finally, it is pushed in trunk.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/