[Toaster] search behaviour

Wed Jul 15 04:17:47 PDT 2015

On Tue, Jul 14, 2015 at 5:53 PM, Barros Pena, Belen <
belen.barros.pena at intel.com> wrote:

>
>
> On 14/07/2015 16:01, "Damian, Alexandru" <alexandru.damian at intel.com>
> wrote:
>
> >
> >Hi,
> >
> >
> >I updated the typeaheads for the project page, using this sort,
>
> Sorry, Alex, I am not sure I follow. Which sort are you referring to when
> you say "this sort"?
>

This sort the one described in the bug; that is:

- entries with names that start with the typed string come any other
entries
- second criteria, the entries are sorted in alphabetical order

e.g.:

if you type "bus" in recipes, you'll get:

busybox          # on first position, because the name starts with "bus"
at-spi2-core    # on second position, "bus" matches something in the
description
dbus-wait        # "bus" is in the name, but the name doesn't start with
the "bus" prefix, and it is sorted alphabetically after "at-spi2-core"

>
> >and using the minimum length for typeaheads at two characters.
>
> This is fine, as far as I can tell.
>
> >
> >
> >The branch was pushed here:
> >
> >adamian/20150708_sorting
> >
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=adamian/2015
> >0708_sorting
> >
> >
> >I am not sure if this is the right solution, pending feedback from Tiago,
> >but it gives you guys a chance to see how it feels.
>
> I've tested the branch, but the results in the typeahead are not the ones
> I would have expected to see. I think I am missing some information to
> really understand what's going on:
>
>
> 1. Which fields are being searched for the typeaheads?
>

All the fields that get searched is a regular way.

> 2. How are results currently sorted in the typeaheads?
>

Using the above algorithm.

>
> Thanks!
>
> Belén
>
> >
> >
> >Cheers,
> >
> >Alex
> >
> >
> >On Thu, Jul 9, 2015 at 10:55 AM, Barros Pena, Belen
> ><belen.barros.pena at intel.com> wrote:
> >
> >
> >
> >On 09/07/2015 10:52, "Damian, Alexandru" <alexandru.damian at intel.com>
> >wrote:
> >
> >>Hi,
> >>
> >>
> >>No, Monday is not late. We can implement it either way - just a note; in
> >>tables, searching and sorting is disjunct, we do them independently. But
> >>we can implement "sortbysearch" on a single field,
> >> and this is what I'm doing.
> >>
> >>
> >>For typeaheads, I have a prototype working doing this client-side. But if
> >>this sort of behaviour is desired in the table pages, too, then it's
> >>worth implementing it server-side as a special type
> >> of search.
> >>
> >>
> >>One more question - is it ok if I trigger the typeahead when the user
> >>input reaches 2 characters in length ? Right now it starts on the first
> >>character, but I think the results of searching on
> >> one character are too wide - it matches everything !
> >
> >Yes, I think that should work fine. Let me know if you see anything weird
> >in the behaviour when you try it, but I wouldn't think so.
> >
> >Thanks!
> >
> >Belén
> >
> >>
> >>
> >>Cheers,
> >>Alex
> >>
> >>
> >>On Thu, Jul 9, 2015 at 10:37 AM, Barros Pena, Belen
> >><belen.barros.pena at intel.com> wrote:
> >>
> >>
> >>
> >>On 09/07/2015 09:46, "Damian, Alexandru" <alexandru.damian at intel.com>
> >>wrote:
> >>
> >>>Hi,
> >>>
> >>>
> >>>I've started working on:
> >>>
> >>>
> >>>https://bugzilla.yoctoproject.org/show_bug.cgi?id=7152
> >>
> >>Ah, great: thanks for taking this on, Alex.
> >>
> >>>
> >>>I wonder if the behaviour described is to happen only in the typeaheads,
> >>>or if it would also apply to the search in tables.
> >>>
> >>>
> >>>Case at hand - in Project compatible layers, when you search "open", do
> >>>you expect to see "openembedded-core" at the top of the list, before the
> >>>layer names starting with "meta" ? Currently, it is at
> >>> the bottom of the search results, because "o" is after "m" in
> >>>lexicographic order.
> >>
> >>Refining the search behaviour would make me really happy, but I am not
> >>sure we can simply transpose the logic from the typeaheads to the tables.
> >>The reason is that search matching in the typeaheads should be done only
> >>against the 'name' (layer name, recipe name or machine name) and the
> >>layer
> >>name (so that I can search for a layer name and get a list of for example
> >>machines provided by that layer. This seems to be working at the moment
> >>by
> >>the way, and I think it's quite nice).
> >>
> >>But in the tables we match against other fields too, most significantly
> >>the description, which is useful because it allows users to type "natural
> >>language"       queries like "small image" and get results. If a search
> >>query
> >>matches against something in a description, I am not sure what the
> >>correct
> >>sorting would be. There is a also a potential conflict in the tables
> >>between the sorting applied and any custom sorting we use for search
> >>results.
> >>
> >>So the answer is that it's worth putting some time into thinking this
> >>through. I am going to ask Tiago if he could look at it and come up with
> >>a
> >>design proposal by Monday EOD. Would that work? Or is it too late? It's a
> >>holiday in Brazil today, so I know he can only start looking at this
> >>tomorrow.
> >>
> >>Cheers
> >>
> >>Belén
> >>
> >>>
> >>>
> >>>Cheers,
> >>>Alex
> >>>
> >>>
> >>>--
> >>>Alex Damian
> >>>Yocto Project
> >>>
> >>>SSG / OTC
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>--
> >>Alex Damian
> >>Yocto Project
> >>
> >>SSG / OTC
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >--
> >Alex Damian
> >Yocto Project
> >
> >SSG / OTC
> >
> >
> >
> >
>
>

-- 
Alex Damian
Yocto Project
SSG / OTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20150715/c3e390e3/attachment.html>