How do you order federated autocomplete groups?

Question

By federated autocomplete (pattern name from this question), I mean one of this:

Background: I am working on an application where there are "types", for example people, documents, transactions, etc.

In a standard search engine/autocomplete without any grouping, we simply display a list of autocomplete items and sort them according to a score the search engine assigns. However, I feel that this can be improved upon by grouping results of the same type together, like Facebook.

Let's say we have a follow list returned by the search engine like so (ranked by relevance):

• People: John Smith
• Document: Invoice-1245632.pdf
• People: David Smith
• People: Jenny Smith
• People: Jenny Citizen
• Document: Meeting-9876.pdf
• Bug Ticket: Platform-14252
• Bug Ticket: Module-Commerce-65322

From the above, we have 3 types: People, Document and Bug Ticket. Sorting the items within each group using the score is easy, but how do we sort the groups?

In the facebook example above, it looks like they have fixed the sorting of groups so that Groups are the most important followed by People, Pages and Apps and perhaps a few other groups.

Here are some ideas I have:

• Sort the groups using alphabetical order
• Sort by the highest score of one of its child items

Is it even a good idea to sort the groups rather than fix them? By fixing them, it would be consistent, so the user can say Ah, people results always comes before page results.

Any real world example of sorting in federated autocomplete and any research/evidence on group sorting would be much appreciated too.

Answer 1

The order of the groups needs to be fixed, unless you have a very good criterion of when to use a specific order. This criterion needs to be very clear to the user, otherwise it's going to be extremely confusing that sometimes groups appears first, and sometimes it's people or apps, to use the Facebook example.

But making them fixed doesn't mean that they're unsorted, they still need to have an order.

Alphabetical order is pretty much meaningless in this case. It's good for sorting a large number of items which have no clearer appropriate inherent sorting, e.g. countries in a dropdown. But sorting just 3 items in alphabetical order is only marginally better than a completely random order.

Sorting by the larger number of items is a bit strange since you probably don't include all your results in the autosuggest, so it's up to you to decide how many results you display in each group. Also, this way your ordering must be dynamic and as I said above, I believe it should be fixed.

I would try sorting it by relevancy. Research or figure out what the most commonly used data type is, and put it first. Or use the one that's most essential to what your app does. The typical number of results might also be a good method - e.g. I think that's why Facebook lists Groups first - the user is likely to have many people and many pages containing the search term, but chances are that the number of groups is much smaller, so the likelihood of displaying the correct one is pretty high even if you've only typed a couple of characters.

A semi-fixed, adaptive approach is to order the groups according to context, but again, this relationship needs to be very clear to the user. E.g. put People first if the search is initiated from a module dealing with people, and Bug Tickets first if searching from a module dealing with bug tickets.