Collaborations

Overview

We collaborated with the Washington iGEM team with both our modelling and human practices teams. We collaborated in a way that improved both our projects, and took advantage of the unique skills of each team.

Washington iGEM

Modelling

As part of our project, we used computer modelling to visualise and test the binding of nanobodies to GFPs. Unfortunately, the accuracy of computer models is difficult to verify, and scrutiny is required to ensure models are reliable. One way of doing this is comparing models created with different methodologies.

To do this, we enlisted help from the Washington iGEM team, who were also modelling protein docking as part of their project. Washington provided us with nanobody-GFP complexes modelled in Rosetta, which we compared to our models generated in LightDock. In turn, we used CABSdock to model protein-peptide docking which they could compare to their models in Rosetta. The details of these models are outlined further in the Modelling section of our wiki.

By comparing and contrasting models created in different programs, both teams were able to refine and improve their models. These models then went on to help verify experimental results, and guide work in the lab. Throughout our collaboration, we learned a lot from each other’s approaches to modelling, and gained valuable skills For our team especially, protein modelling was not something we had a lot of experience with prior to iGEM, and having another team to work with and learn from proved invaluable. We cannot thank the Washington team enough for their hard work.

Podcast

Because we were already collaborating with Washington iGEM on the modelling side, we realised that the putative applications of both our and Washington’s projects were in at-home or point of care (POC) diagnostic testing. Upon further discussion, we realised that the healthcare systems in our respective countries, the US and Australia, could mean that both of our projects could have very different impacts in the different countries. To explore this idea further, we decided to record a collaborative podcast where we would discuss our different perspectives and experiences regarding healthcare and POC testing.

To create the podcast, we had three different meetings with the Washington team. During the first two meetings we discussed which ideas we wanted to discuss in the podcast, and made a more concrete plan for how it was to be recorded. During the third meeting, we recorded the podcast via Zoom. Once we had done some light editing to the audio recording and written the transcript for accessibility, the podcast was ready to publish on the wiki (final recording and transcript of the podcast can be found in the Human Practices page).

During the process of creating this podcast, both of our teams gained insight into the cultural experiences of each others’ countries. We also learned about the unique challenges present in the healthcare system of each country, with special attention to how those challenges affect POC testing and our project in particular. This experience made us both consider potential impacts of our projects that we may never have come across otherwise.

NSW iGEM Meet-up

A zoom screenshot for our NSW iGEM meet-up.

The official NSW iGEM meet up on the 6th October 2022 was attended by members of the usyd, unsw and kings school iGEM teams. During the meetup we exchanged the details of our respective projects and their trajectory throughout the competition. Additionally, we shared our personal experiences and feelings in regards to our participation and satisfaction in the competition as a whole. The kings team, participating in the highschool track, asked members of the university teams for some data analysis advice as they no longer had access to their laboratory and advisors due to commencement of the school holidays in nsw. It was a nice break from more serious matters that let members of each of the teams decompress and socialise.

A poster for NSW iGEM meet-up titled iGEM Down Under. Date: October 6, 2022; Time: 2pm - 4pm AEDT; Location: virtual.

USYD, UNSW and Kings School Wiki Collaboration

The three team wiki leaders (shown in the image: Mark, Kiran and Kobe in order) worked on a collaboration to deliberate design choices, formulate coding advice for each wiki team, and to work together in constructing wiki websites with satisfactory design and good coding practices. Along with the details listed below from the three online meetings, a significant amount of progress was made in discussions through texting in a Discord group chat. In summary, we aided each other in design choices, making decisions on workflow and extensions to use for website building, and ensuring that all iGEM rules and guidelines were followed in both our content and coding resources.

A screenshot from one of our wiki meetings, featuring Kiran Muthukrishnan (USYD), Mark Hong (UNSW), and Kobe Goodridge (Kings School).

The details discussed during the meetings are as follows:

27th September, 2022

Attendees: Kiran Muthukrishnan, Kobe Goodridge

The discussion was focused on appropriate scripts to source and use for animations, and website accessibility. The initial perspective was that the default flask app and bootstrap bundle provided in the iGEM GitLab repository greatly reduced the freedom for designing the web pages.

Kobe had previously decided to scrap the flask app and run with blank html, converting the workflow to designing the pages first then choosing the app to run it on later. However this created problems with his [.gitlab-ci.yml] file, which required different formatting to build and deploy his website.

I (Kiran) was still at a crossroads because the web design progress had been stifled by the limitations of the flask app through how fast it built its local app, but understood that it would be a lot more time consuming to start from scratch as Kobe had done.

28th September, 2022

Attendees: Kiran Muthukrishnan, Kobe Goodridge, Mark Hong

In this meeting we were greeted by Mark Hong, who gave very useful input to our problems. I learned from Mark that sticking to the flask app, given the time constraints, was the best practice moving forward in order to maintain consistency in design. I also chose to keep the bootstrap bundle and learn more about bootstrap 5 packages and functions to make use of the bundle itself rather than focus on what I had learned about intermediate design from Udemy. This proved very useful in the future.

Kobe was still having problems with his [,.gitlab-ci.yml] file, despite the help he had recieved from the iGEM global Slack community, and therefore had to start looking for a new app template. My problem with loading the json-animated icon as a splash screen animation was solved by compromising on the animation, and instead loading the animation into the homepage title banner.

Mark's progress on the wiki appeared consistent and organised. His design for paragraphs compressed to decrease scrolling involved accordion elements, which inspired my choice to use them for the paragraphs we recorded for the notebook.html webpage, ordered by week. He discussed how a lot of the website's initial design was coordinated by the team on Canva beforehand, but was only advisable for early stages of the website design.

2nd October, 2022

Attendees: Kiran Muthukrishnan, Kobe Goodridge, Mark Hong

This later meeting was created to update everyone on the design progress, and then compare and review each others designs. Kobe's website boasted quick progress thanks to being able to use live server on his wiki pages after omitting the flask app. His design choices were both creative and witty (including his humorous meme GIF that auto-loaded in for empty pages).

The accordion element containers for the notebook webpage had worked quite well for the USYD page, on Mark's advice. Mark also advised on consistency of layouts and design choices throughout the wiki for a more comfortable visual experience for the user. My progress in working with bootstrap class declarations had grown quickly, and add-on javascript and CSS was introduced only where the design changes needed were simple, or for added visual experience (such as shadows when hovering over icons). Overall, all our designs were progressing well.