Clinical Attributes + Column-Based Filtering in Mutations Table (Results View)

[Rajat-Sirohi]

Clinical Attributes

Currently, the "Columns" drop-down menu in the Mutations table only includes attributes for the mutation. I would like to include clinical attributes from the sample (e.g., race, age, sex) as potential columns as well. The new drop-down will resemble that of "Add Tracks" from OncoPrint, with an additional column for the existing mutation attributes:

Filtering

Additionally, there has been an expressed demand for greater filtering functionality (see cBioPortal/icebox#140). Currently, there is only a search bar which filters the "Sample ID" column based on a simple .includes(...) method.

In addition to this search bar, I would like to add a filter for each column in the Mutations table, with data-sensitive options similar to that found in Excel. Each column will have an inactive filter-icon in the top-right by default, which when clicked will open a list of options based on the type of column data (numeric or text); selecting an option will open a separate window asking for the appropriate input, after which the filter-icon will become active:

Once a filter is activated, it may be either modified or removed by clicking on it once more:

There will be support for only one filter per column, but multiple filters across multiple columns simultaneously.

Plan

This proposal naturally divides into two milestones:
(1) Replicating the OncoPrint drop-down menu with the clinical + mutation attributes in the Mutations Column menu (#8657)
(2) Adding the column-based filtering functionality

cBioPortal/GSoC#89 summarizes the goals of this proposal.

Discussion

There remain lingering questions and room for suggestions. Please provide any input on the following or other considerations:

• Does the filter being in the top-right of each column by default make sense? Will that be annoying when trying to sort by column?
• What about columns which have neither text nor numeric data, e.g., "Annotation" column? Unique filter or no filter?
• Is there desire for multiple filters per column? How to handle potentially contradictory filters?
• Are there any legal complications with copying Excel's filtering functionality / icon?

[tmazor]

@Luke-Sikina @Rajat-Sirohi updates from today's steering call:

Menu for adding clinical/mutation attributes to table:

• Put 'Mutations' tab before 'Clinical' tab
• Keep Freq column for Clinical tab, but do not include Freq for Mutations tab
• If a variable is already coded as clinical (eg Cancer Type), then keep it as Clinical and do not include in Mutations

Filter:

• For numerical data, prefer a slider (as in GoogleSheet-like filtering icebox#140) but in addition to the slider, must also allow a user to enter numbers for the min/max values
• No further discussion on categorical data today, will revisit this later

Sorting:

• If sorting multiple columns, the sort order of the first column should be remembered when sorting the second column.
• Future improvement might include an interface to enable multi-column sorting.

@jjgao @schultzn anything I missed?

[Luke-Sikina]

• For the filter icon, we can use the font-awesome icons: https://fontawesome.com/v5.15/icons?d=gallery&p=2&q=filter

  • Edit: this may not be worth it. I doubt we use font-awesome pro, so we wouldn't get the filled and wireframe icons. Maybe we could solve this with some css magic, but just making our own svg may be easier.

• For the between [n] and [m] option, the slider sounds good; instead of having a separate UI to enter a precise range, why not just make the values on either side of the slider editable? Ex:
  

• Doesn't the slider option cover <=, <, >=, >, and between? Condensing all those options would make the UI a lot less cluttered.

• If we want to have a reasonably compact filter UI, large numbers and floats will pose a problem. How do we want to represent them? Do we limit significant digits?

[tmazor]

Replies to @Luke-Sikina comments:

• We already have filter icons in study view in the genes tables - can we just reuse those?
• That's actually what I meant, I just didn't write it clearly :) A slider with editable values sounds perfect.
• Yes, a slider covers all numerical options - I think the slider alone is all the UI we need.
• Good question - I don't have a good sense for the range of numbers that we have across all studies, so it's a little hard to say. I suspect limiting floats to a few (2?) digits would probably be fine. For large numbers, I'm inclined to say just show them as is, but maybe I'm underestimating how large the numbers actually get.

[Luke-Sikina]

All those responses sound reasonable. We can totally take a wait-and-see approach to large numbers. It's not like we're wasting dev time by displaying them naively. Thanks for the reply.

[Luke-Sikina]

Categorical Data

The filtering options for categorical data should have two main means of filtering:

• Multi select
• Text search

The multi select should look similar to this:

The text search should have the following options, in this order:

• Contains
• Does Not Contain
• Equals
• Does Equal
• Begins With
• Does Not Begin With
• Ends With
• Does Not End With
• Regex

The UI should look something like this, but with Regex added, and the order modified:

All forms of text search should be case insensitive

[inodb]

This has been implemented