konradjk / exac_browser Goto Github PK

color discrepancy .. missense variant represented as yellow in the figure and green in the table. While green in the figure is for synon and in the table it is black

Some variants, such as:
http://127.0.0.1:5000/variant/1-12065926-C-G

have a blank gene entry (displaying correctly -- the variant object actually contains a blank entry).

Potentially bigger issue is that variants need a standard representation

http://127.0.0.1:5000/transcript/ENST00000514858

Lots of JS to fix up anyway

If you type a valid lower-case gene name into the search bar and just press enter without accepting the auto-correct, you get an error message. A valid lower-case gene name should just auto-direct to the appropriate gene page.

Looks close, but this looks odd, e.g. http://127.0.0.1:5000/gene/ENSG00000198062

In every case, looks like there is downstream intron overhang, but not upstream - something seems weird about that.

So if you search for a singleton variant by itself (e.g. 22:36649965) the frequency bar in the right-hand column looks like it's very high. This bar should be absolute, not relative.

Don't allow someone to scrape the whole site

It should be abundantly clear that this is an early release. Put the term "beta" everywhere and make it easy for users to file bug reports.

The more I look at large genes, the more I think we should just have a fixed dimension on the x axis and just make users scroll sideways for big genes, and also add actual numbered coordinates on that axis. At the moment the display is really uninformative even for moderately large genes. Critically, at the moment there's no easy way for a user to quickly examine coverage in exons of interest in large genes - there's no actual coordinate system shown on the x axis and in large genes everything is squished together.

i.e. searching ENSG00000116688 does not work

Get rid of the public dataset links

Right now we accept RSID for variant input. We should allow clinicians to enter F508del, among other things

i.e. multi-allelic variants - find_one() won't work here

Instead of storing raw values

Current behavior is dynamic (i.e. 0->max(individuals above x))

Resulting in awkward intermediate load state

This will be critical for many clinical groups - output search page in well-formatted CVS for loading up in Excel.

Don't display 10000 variants and 1000 genes

Currently pos but not chr is present.

This will be critical for many clinical groups - output search page in well-formatted CSV for loading up in Excel.

It is taking too long for the page to load up when all variants are displayed as default