Refactor system table filter and sorter

[qjiang002]

This PR is related to issue #485

Previous filters and sorters

Refactor: move filter lists and sorter to the system table header

• It passes the filter and sorter settings to the backend client and retrieve a new list of systems every time.
• It supports one sorted column at a time as before. The default sorted column is Created At in descending order.
• It can also update and parse the settings in the url.

[qjiang002]

New commit: support search by system and dataset name with a single search bar.

[pfliu-nlp]

hi, @qjiang002 Cool, thanks for such a fast implementation.

"support search by system and dataset name with a single search bar."

I wonder whether it could work when users just type a system name, such as bert or they must type system:bert? I'm not sure if the latter one is convenient enough.

[qjiang002]

Now it requires the prefix "system: bert" to search systems. One way to simplify this is to add a dropdown list before the search bar to auto-fill the prefix. WDYT

[neubig]

@qjiang002 : what about if it doesn't start with "system:" or "dataset:" then we allow it to search any field. Would that work?

[qjiang002]

Thanks @lyuyangh for the detailed suggestions! Here are some of my thoughts to improve the filter/sort function.

[system/dataset]

• I agree that it can be clearer to use separate search bar for systems and datasets. For systems, we can keep the search bar above the table as before. For datasets, we can put a searchable list similar to the language dropdown list at the dataset table header.
• As for @neubig 's suggestion of searching for system and dataset together, I think users usually want to compare systems using the same methods or using the same datasets, which can be handled by searching by system/dataset/tag separately. Is there any use case that users need to search them together?
• Highlight the filter columns if they are filtered.

[sorting]

• The metric columns in the table depends on what systems are displayed in the current page, so some metrics are not visible / sortable if there is a system using this metric on the current page. One solution is to use a separate sorting input above the table as before, which will make the filter section longer. If we keep the sorting in each column, we may need to display all the metric columns all the time, which will make the table longer. I would prefer the first option because I find it harder to look for a metric name in the column headers.
• We should pin and highlight the sorted table column.

[neubig]

As for @neubig 's suggestion of searching for system and dataset together, I think users usually want to compare systems using the same methods or using the same datasets, which can be handled by searching by system/dataset/tag separately. Is there any use case that users need to search them together?

I was just thinking that it's easier to type "sst2" than it is to type "dataset:sst2". If we have separate search bars I think that's not really an issue.

[lyuyangh]

@qjiang002 Sounds good! Let's have separate search bars for the dataset and system names. And yeah, I think we can put the sort column selector in the search bar for now. That seems easier to do and it also provides a better user experience. If you want, feel free to split these into multiple PRs.

[qjiang002]

This PR is closed as it is split into separate PRs #528, #529, #530.