We have been highlighting lab design list for analysis in our little group and I thought it would be useful in game for others too.
I have been brainstorming some view oligo inputs views options for the lab list with input from Eli. Using the energy modeling to show oligo inputs placement in the sequence.
I have asked other long term players for feedback/options to refine the view/ideas, like I have in the past for other ideas.
Any feedback would be great. I’m happy with any reply of what you think of those if any were Good, Bad and What was I thinking.
I imagine the difficult part here is that MFE structure predictions are not saved (*disclaimer: this could have been changed recently, but I wouldn’t know).
Would the goal be to have every submitted sequence be parsed and compared to the sequence of the oligo to find the best matching sequence?
It’s true that the MFE predictions aren’t currently being stored, and I doubt they ever will be for the legacy browser. But I think it is a an important feature for the new browser, because filtering on predicted substructures will be very powerful. So they will get there.
One of the advantages of the new browser is that there are no hard-coded assumptions about what columns can be put into the database. In fact, its database already has fields defined for four 2D structure strings. So the issue is not code to support the structures, but in getting the structure data into the database.
This was an issue for the (pre-browser) FMN lab fusion tables as well. In that case, Meechl volunteered to do the legwork of manually running a script on Nando’s dev server multiple times and, along with other data, created a spreadsheets of “extra” results. I then merged that data into the fusion table that Eli or I had previously created and made it public.
The situation is basically the same for the new browser database, but the details differ. Nando’s script that Meechl used doesn’t handle RNA inputs or outputs, so we have to develop a new procedure. Part of that involves Javascript coding, i.e. creating a utility that loads the Flash app, queries the Eterna server for the set of puzzle designs, submits each design to the Flash app for folding, gets back the results, and enters them into a spreadsheet. But that’s a one-time effort. The on-going effort is actually to go through that process of running the app and verfiying the results for each puzzle, both for new labs as the data is released and old ones as they get added to the database.
The time I have available right now is split among a number of different tasks:
Addressubf current browser issues, from outright bugs to cosmetic improvements,
Adding features that long-time players feel are necessary for the new browser to be “good enough” to make the switch from the legacy one.
Adding URL-directed invocation capabilities. By this, I mean making it so that a properly constructed URL can load the browser with specific set of designs, columns and capabilities. The tutorials have a couple of simple examples already, but Rhiju is eager for a lot more generality, so that links to specific data can be an integrated part of the game UI.
Add entirely new browser capabilities (which wasn’t really feasible with the flash code.)
Get more data into the new browser’s database. This covers both new projects and filling in “holes” (like the 2D structures) in the data for the projects that are there.
It is because of all these different things that I really can’t give a timeline for anything until it gets to the top of the priority stack (which is always changing.)
Having said that, though, if a player were to say that they would take on the routine process of extracting the structure data for each lab, I would be very motivated to put the coding of the needed utility very high on my list. (Say by the end of next week.)
@Mat, I think there is real potential here. I added a comment to the doc saying I would be interested in seeing what it would look like to combine the traditional coloring of bases with outlines showing structure. I decided to spend a little time experimenting myself:
This is just a rough cut; the details aren’t consistent.
It would certainly take some time for a player to look at something like this and grok the full meaning. But even without that, I suspect that a just a glance will say something about how promising a design is, because good designs are more likely to look “tidy”, while ones that look “messy” are likely not to switch well.
This reminds me - the other day I had a case where I really wished I had a sequence highlight, while I was using the sequence search option in a lab analysis.
Usually in the lab data, the oligo position is clustering a lot for the high scoring designs, making it a bit easier to pull the data out. But when deliberate experiments have been carried out and position varies a lot, it can be a lot harder to see the wanted sequence.
@Eli, I agree that highlighting (in some way) the searched-for sequence could be very helpful.
I spent some time looking into how this might be implemented, and it turns out that with the datatable library I’m using, it is not at all clear how to achieve outlining of subsequences. In the past, I have done this by defining and coloring borders around wash base letter. But the datatable code is managing that aspect itself, and is overriding my attempt to achieve outlining. At this point, I don’t know whether or not it will be feasible.
However, I prototyped some other other possibilities, and here’s the one I thought worked best:
@Mat, my above comments about being unsure of the prospects for incorporating subsequence outlining into the main table isn’t meant to discourage the UI View Box discussion. Assuming this view box is implemented as part of some kind of separate view (as opposed to be being a mode for viewing the complete table), there would not be any compelling need to use the datatables library for that.
@Omei, this is sweet news! I really like what you have been up to. This looks good. I would definitely wish for that option.
Only additional wish is a slight change of colors for the background of the highlighted changes, so the sequence gets a little less weak in the colors, for easier reading.
@Eli, I tried various shades of white to light gray, and this looked the best to my eye. Anything whiter and there isn’t enough contrast in the luminance to read one or another of the nucleotide letters easily. (Edge detection in humans seems to depend mostly on changes in luminance, ignoring hue.)
We all see color a little differently. Does this look better or worse to you?
Of course, anyone else is welcome to express an opinion.
I don’t see your comments in anyway discouraging the UI View Box discussion, you are only outlining. How feasible it would be to incorporating sub-sequence into the main table.
I like the feedback and good to know how feasible our suggestions are, plus you having given possible work around options and examples.
@LFP6, the sense that there is a semi-transparent overlay is an optical illusion. Only the background color is changing.
But your comment does evoke another thought – there is no reason we can’t tweak the text luminosity as well as the background’s, if the end result is better subjectively.
If one of you are interested in making the selected text display better, perhaps you could experiment with a Google Doc (or any other text editor that allows full control over foreground and background text color) and post an example of what you think works best.
