Team:Imperial College

Project

OVERVIEW

Project

Human practices

People

values

Our project is built on a strong foundation of  core values, ultimately enabling use in the lab and future development  by adhering to these values.

Communication

We sought to set a precedent for a strong line of communication between our team and end-users throughout the design process, and for all aspects of our project. Click the Dan-Bot for more info!

Accessibility

We sought to ensure the accessibility of our project, both so our end-users can utilise our product agnostic of their experience, and future teams can build on our progress. Click the Dan-Bot for more info!

Validation

We sought to provide proof for validity and therefore trustworthiness of all aspects of our project, seeking input and feedback from external sources to remove bias. Click the Dan-Bot for more info!

Early development

Our ideas evolved a lot over the summer and were captured early as a snapshot at the German iGEM Meetup. Here is a link to our first promotional video that we made in July so that we could find collaborator with other teams. This helped us find our main Partnership team, iGEM Hamburg. We also have an iteration of our plans as a PDF captured here in this flyer below!

Check out our project page to see how we developed from this point onward!

validation

We chose validation as our third key value. For us, maintaining this value is about ensuring that we are providing a product that will be useful and attractive to our end users, and that users can trust in the quality and viability of our tool. Furthermore, validation was integral for ensuring that we were maintaining our other key values, communication and accessibility.

There are two sides to our validation, which can roughly be defined as qualitative and quantitative validation. Qualitative validation is about obtaining feedback from users and adapting to it, measuring how well our functionality and interface fit our users’ needs and expectations. External feedback is crucial for eliminating bias and ensuring that our project fulfills our end users’ requirements. Quantitative validation involves rigorous testing of our product. For the software side of our project, this can mean extensive unit testing and error checking. In the wet lab, we need to evaluate the success of assemblies performed by an Opentrons running scripts generated by our tool. We are using quantitative validation to demonstrate to users the viability of our tool, with the intent of increasing confidence in using automation and software in the wet lab.

By adhering to these values, our project will be built on a strong foundation, ultimately enabling use in the lab and future development.

Some of the ways we integrated validation into our project were:

 Demonstrating our software to other iGEM teams at multiple stages and recording feedback
 Conducting interviews and surveys with experts about different aspects of our project, such as with the creators of SBOL
Obtaining expert opinion from two webinars and using it to evaluate our decisions and approaches throughout the project
Implementing continuous integration into our GitHub and writing unit tests for our code
  Regular testing of our software as a team
 Conducting wet lab experiments to assess the performance of our scripts, and how their performance compares to manually carrying out protocols

 Hide

communication

“There's definitely a lot of people interested in this idea. But I'm still doubtful about how it translates to people in the lab. A dialogue between software developers, hardware developers and lab users is most definitely essential.”
- Alice Boo, PhD Imperial College

To bridge the gap between developers and end users, we wanted to set a precedent for a strong line of communication throughout the design process. As part of this, it was important to clearly define who exactly are the end users. We aim to primarily target wet lab synthetic biologists, especially those in smaller labs. This also includes iGEM teams, who we believe can greatly benefit from our pipeline, especially because of the nature of the competition, in which sharing data and efficiency are often crucial for success. 

Some of the ways we bridged the gap in communication between developers and end users include:

  Holding a webinar in which lab scientists and software engineers discussed how they have been collaborating both in academia and tech companies

  Adding manual protocols to our website to help lab scientists understand the assembly protocols they were running

 Integrating and modifying tools previously difficult to access or inaccessible without coding experience such as SBOL Designer, DNABot, and DAMP Lab’s MoClo tool

  Increasing SBOL literacy by promoting it and educating users on its use, such as through demonstrations to other iGEM teams

  And finally, informing our features and designs with end user feedback

 Hide

accessibility

For end-users, we want our product to have a quick set-up, and an intuitive interface to be approachable and easy to use, agnostic of a user’s experience with software. In addition, we wanted the tools we developed to be accessible to software developers for future development and integration into larger pipelines. Therefore, in the spirit of open-source, we followed a rigorous documentation standard so teams in the future can easily build upon our software. Accessibility is very important to us as we see it as one of the primary barriers to synthetic biology automation. We also hope that by providing wet lab synthetic biologists with a more transparent, intuitive experience we can increase their trust in software tools and automation. 

Some of the ways we ensured we prioritised accessibility were:

  Hosting our software pipeline on a website, so that our software can be accessed regardless of user hardware or software
  Maintained careful documentation and follow a strict linter so that our code is easy to understand, modify, and integrate
 Ensure our tool is intuitive for everyone, regardless of programming experience, by obtaining and adapting to end user feedback
  Chose Opentrons as our liquid handler, one of the most affordable and therefore accessible liquid handlers on the market
  Included MoClo (Golden Gate) and BioBricks in our assembly methods, assembly methods popular among iGEM teams, so that our pipeline can be useful to as many teams as possible

Hide