Judging

Jamboree

Key Papers

We cited lots of papers on our wiki which makes it hard to see which ones are the most important. To make it easier for anyone reviewing our project, or wanting to get a better understanding without spending years trawling through tables of cancer statistics, we have compiled the following list.

Toehold Switches, their design and use

• Green, A. A., Silver, P. A., Collins, J. J., & Yin, P. (2014). Toehold switches: de-novo-designed regulators of gene expression. Cell, 159(4), 925-939. DOI: 10.1016/j.cell.2014.10.002
• Green, A. A., Kim, J., Ma, D., Silver, P. A., Collins, J. J., & Yin, P. (2016, September). Ribocomputing devices for sophisticated in vivo logic computation. In Proceedings of the 3rd ACM International Conference on Nanoscale Computing and Communication (p. 11). ACM. DOI: 10.1145/2967446.2970373
• Pardee, K., Green, A. A., Takahashi, M. K., Braff, D., Lambert, G., Lee, J. W., ... & Daringer, N. M. (2016). Rapid, low-cost detection of Zika virus using programmable biomolecular components. Cell, 165(5), 1255-1266. DOI: 10.1016/j.cell.2016.04.059
• Machinek, R. R., Ouldridge, T. E., Haley, N. E., Bath, J., & Turberfield, A. J. (2013). Programmable energy landscapes for kinetic control of DNA strand displacement. Nature communications, 5, 5324-5324. DOI: 10.1038/ncomms6324

Micro-RNAs as Biomarkers

• Hennessey, P. T., Sanford, T., Choudhary, A., Mydlarz, W. W., Brown, D., Adai, A. T., ... & Califano, J. A. (2012). Serum microRNA biomarkers for detection of non-small cell lung cancer. PloS one, 7(2), e32307. DOI: 10.1371/journal.pone.0032307
• Etheridge, A., Lee, I., Hood, L., Galas, D., & Wang, K. (2011). Extracellular microRNA: a new source of biomarkers. Mutation Research/Fundamental and Molecular Mechanisms of Mutagenesis, 717(1), 85-90. DOI: 10.1016/j.mrfmmm.2011.03.004

Wiki

We've really tried to go for Best Wiki this year. The most important part of course is the content. We used Google Docs to write and work as a team - resolving a total over 400 comments. Adam, our student leader who did the bulk of wiki editing made over 1300 edits - and as a result has gone slightly insane.

One problem with previous wikis is that they were inaccessibly written - often lacking good explanations and having little page structure. This is likely down to the last minute rush before the deadline. We started early and spent a long time perfecting our text so hopefully you find it all makes sense. We also had several people on our team test our wiki, checking links, proofing text and ensuring the more advanced bits worked as they should.

Another problem is that previous wikis took ages to load. Part of this is down to iGEM’s servers, but most of the problem stems from poorly written code. Large swathes of redudant code often lurk in the shadows, and images are commonly uploaded uncompressed at very high resolutions. We saw some homepages well over 10MB! Our homepage weighs in at a lean 0.7MB, and all our other pages are similarly optimized. We've done this by analysing our site with Google's Pagespeed and Lighthouse auditing tools, and made large gains by correctly sizing and compressing images, reusing files so they can be cached and using SVGs where possible.

As SVGs can be embedded more easily into the page, page load times are improved as the browser doesn't have to fetch the images seperately. SVGs also allow for infinite scalability allowing our wiki to take advantage of high resolution screens like Apple's 'Retina Displays'. They're also powerful as they allow text to actually be text rather than pixels - allowing screenreaders to read diagrams, improving the accessibility of our wiki. The worst cases we’ve seen are are wikis that are just huge PNGs - they take forever to load, don’t allow you to select text, are inaccessible to the visually-impaired and lack links and citations embedded in the text.

To make navigation as easy as possible, we've used the default iGEM pages and spent a long time thinking about the structure of the rest of our site. The navigation bar was significantly revised four times in efforts to make it as easy to find the relevant pages as possible, and we've tried to avoid using hidden nested subpages. We set up several redirects to make it easier to guess links, although we believe they shouldn’t be required with our navigation bar. In addition, we scattered links throughout our text to prevent you having to hunt for the right page when we reference another part of our project.

We believe many teams don't take full advantage of the template system Mediawiki offers. By compartmentalizing all the repeated sections we made our code more readable, allowing members of our team with no coding experience at all to go in and edit sections (unfortunately they won’t now stop talking about how they’re programming geniuses). Templates also makes it easier to update styles - ensuring all our pages have a consistent feel that makes navigating them easier and look better.

We shared a lot of this knowledge with other teams, including Judd School, University of Westminster and Carroll High School. More information about this is available on our collaborations page.

All our code was written by current team members, except the small bits otherwise attributed. All images which we didn't make ourselves are attributed beneath the image. Images without explicit licenses are reproduced with written consent of the rights holders.