Ann Loraine, who is part of the IGB team, explained that the Integrated Genome Browser (IGB) is an older genome browser that predates IGV. The IGB team had attempted to add multi-locus functionality more recently, but they found that it was no longer possible to make such a fundamental change to the architecture of IGB. All software developers have to make assumptions when starting a project, but it’s important to examine those assumptions and consider what all the features are that we might eventually want to include. That is why future-proofing is such an important topic for this discussion.
To highlight another dimension of future-proofing, Valerie Schneider of the NCBI pointed out that a flood of new genomes, especially from the Vertebrate Genome Project, is one of the challenges she sees on the horizon for the NCBI’s own genome browser. Valerie also mentioned that enabling the genome browser connect to data from government and consortia resources would be very important.
Christian Stolte of the New York Genome Center showed a mini-browser within MetroNome that visually connects protein domains to their genomic coordinates along a gene. That example brought up an interesting point that non-genomic coordinates such as transcript and protein domains could also become first-class citizens. So then I guess we are no longer just talking about a genome browser but actually a multiome browser!
Notice that all of these use cases we discussed for future-proofing are already needed today and supported by niche mini-browsers. If you know of other current and predicted future use cases that are not already covered by existing genome browsers or by the ideas presented here, please add them in the comments, so we can all broaden our horizons and expand our vision for the ideal genome browser.
A library of community-contributed plugins
Before I built each of my own visualization tools, I tried to add the functionality I wanted to the genome browser I was using at the time, the desktop version of IGV. First, I needed to show two loci at the same time, with connecting lines between them for long-range variants. IGV could show two regions at once, but they were independent and I couldn’t draw lines across them — so I built a visualization tool called SplitThreader to show long-range variants as connecting lines between two loci. Later, I needed to show alignments of long reads in a way that you can tell where the alignments are along the read’s own length in addition to where they are on the reference, so I built Ribbon. The funny thing is, after building the parts of the visualization that are really novel, you still have to add several parts that normal genome browsers can do just fine, like drawing genes, variants, other features from a bed file. I would end up spending over 50% of my time implementing features that already exist elsewhere, and pretty shallow versions of them too.
Since starting my data visualization role at DNAnexus I also have a whole new appreciation for modularity because the platform is built to be able to run virtually any kind of analysis on any kind of data applicable in genomics. I dream of having a genome browser that could be equally flexible and modular, that anyone could contribute new types of visualization to, and that could be integrated and used anywhere from consortium database explorers to digital paper figures. If anyone can build an app on DNAnexus or Galaxy and publish it for others to use, then why is it not the same for adding a special track to a genome browser?
Conclusions
I would like to mention that the genome browsers out there right now are fantastic. When thinking about this ideal genome browser, there are several ideas that come directly from existing tools: IGV.js is very lightweight and does an excellent job of being embeddable anywhere, while JBrowse has a library of community-contributed plugins that I find very encouraging for collaboration in this field.
Genome browsers have significant similarities with each other, but each one also has its unique strengths that not all of them share. When I need to build a novel visualization for a particular data type, concept, or application, I would love to be able to just build a track into an already powerful and full-featured genome browser, instead of building the novel feature into its own tool and then adding genes, bed, and variants track types. The users of my tools would surely rather have the full power of an IGV or a JBrowse at their fingertips even while looking at their long-read alignments in a Ribbon browser.
Now I would love to hear what you think!
Are there any genome browser teams out there who have been thinking about modularity, plugins, future-proofing, and making a lightweight yet powerful genome browser for the web?