People view has no particular order

[Brendan Donegan]

When browsing the 'People' view in launchpad-results, it looks like there is no particular order: http://107.20.153.224/people

Certainly it's not alphabetical, and the dates don't seem to be in order either, so if it is in some order then it's not one that the user can discern from the information presented.

The phrasing of the sentence at the top 'These are the latest people testing' suggests a date order, but I don't see in what way that is useful. I'd be inclined to alphabetical ordering.

[Marc Tardif (cr3)]

Agreed, the people listing should be alphabetical on the person's name attribute. However, the problem is that I haven't quite figured where it would make the most sense to define a default ordering for something like a person set. In the current design, it could make some sense to define the default ordering as a class attribute in the PersonSet which would be checked by the base SearchSet class when building the query. It could also make some sense to define the ordering as a default value in the constructor of the PersonSearchParams class instead of letting the base SearchSetParams set the value to None. Both solutions would work but not sure which might be more desirable.

[Brendan Donegan (brendan-donegan)]

Seeing as I raised the bug I should probably give my input. As an outsider to the project, but with my coding hat on, it makes the most sense to me to define it as a property of the query, i.e. in PersonSearchParams. Now that you've indicated where this can be done I might have a look at implementing it - although I'm not sure where I'd get data to test it (since I haven't got a results tracker instance setup)

[Marc Tardif (cr3)]

Note that the ordering is already an attribute of the PersonSearchParams class, inherited from the base SearchParams class. The question is whether its default value should be defined there or in the PersonSet. One of the considerations is that the SearchParams subclasses are currently implemented as empty containers to be filled at run time with search parameters, kinda like the Data Transfer Object pattern. I'm afraid that starting to define default values there may break the pattern, like when using the PersonSearchParams class in a context unrelated to the web interface for example.

As precedent, consider looking into the BugTaskSearchParams class in Launchpad. It is also defined similarly to the SearchParams class with empty attributes. The default value for ordering is defined elsewhere in the keyword argument to the fromSearchForm method.

[Marc Tardif (cr3)]

The SearchSet base class is derived by several classes in addition to the PersonSet, and the same applies to the corresponding SearchParams base class. So, it is worth coming up with a solution that could be used consistently throughout all these derived classes. This is especially true considering that unordered search results aren't really useful, making it worthwhile to apply across the board.

With this context in mind, I've been thinking of ordering search results for systems by relevance. The problem with this ordering is that the actual search text converted as grams needs to be passed to the order parameter. This cannot really be done in the context of the SearchParams but rather in the SearchSet, more specifically its derived class. This will require some modifications to the existing SearchSet methods where the ordering parameter is sometimes passed without the text.