Resources/Telling your Story

Introduction

The goal of this information is to help teams understand the importance of scientific communication in terms of explaining their work to a larger audience and documentation as it pertains to the iGEM competition for medals and special prizes for the 2016 season. Telling your story in a clear and concise way is challenging, but well worth the effort in the end.

Everyone involved with your iGEM team should make sure to read through:

Following all of these requirements is the responsibility of the entire team, which should be shared by all team members and not just a select few.

For the Public

Remember, your wiki is the public-facing representation of your project! The general public will see it, so your story overview should be clear to non-scientists and you should be able to guide them through the different parts of your project at a high level through your wiki pages. Everyone on the team should take pride in the wiki and we recommend that everyone on your team help contribute some material for it.

For the Judges

This is also how the team's judges will first learn about your project, so you should make sure your story, design, and results are clear to someone who has never seen your work before. You might want to ask other Professors and graduate students to read the wiki as you build it, to make sure other scientific experts can understand your project from just your wiki alone.

Tips for Working on the Wiki

Assign weekly tasks for the wiki during lab meetings

Start to create content and decide on the layout and design as soon as you start your project. Teams should decide on weekly tasks and assignments for the content for their wiki during regular lab meetings. You could easily work on the content while you wait for reactions to finish or gels to run in the lab!

Instructors and mentors should be proofreaders for the wiki

As your team creates content and posts it on their wikis, ask the team instructors and advisors, and anyone else who would be helpful, to take some time each week to read through the wiki and ensure the content has been proofread for typos, clarity, and accuracy.

Assign specific pages to specific people

Ideally, each team member will be creating content for the team wiki with a smaller group responsible for editing the wiki and posting the content to the page. To avoid confusion and possible deletion of content, you should make sure the editing of each page is specifically assigned to one person.

Updates done on the Wiki Freeze Day should be minor edits

We strongly recommend that the vast majority of your content should be on the wiki a full week before the Wiki Freeze so you have plenty of time to read through everything and make sure you haven't missed any critical item. Only minor edits should be done during Wiki Freeze week. This will greatly reduce the stress on your team members!

Project Overview

Having a brief, well-written project overview is a huge help for anyone interested in reading about your project. The overview should only be a few paragraphs in length and often teams will include a cartoon or diagram to accompany their overview. Ideally, the overview should be understood by scientists and non-scientists alike.

Recommended Components for a Clear Overview Page

  • State the Problem: Very briefly, state the problem you are attempting to solve in non-technical terms.
  • State the Solution: Describe how you plan to approach and solve this problem at a high level.
  • List the Goals: If appropriate, briefly give your project goals that will help you achieve your solution. Try to avoid getting into a lot of details.
  • Link to Details: Add links that will take people to the more detailed description of your project, the problem, and your solution.

Examples of Well-Written Overview Pages

Here are a handful of well done project overviews. These examples show different ways that the project overview can be done on the team wikis. These are all concise, well-written project overviews with links to more detail.

Overview illustration from the 2013 SYSU China team

Project Design

Project design pages should be where you delve into more details about the genetic devices, software, hardware, and anything else you intend to work on and build over the course of your project.

Recommended Components for a Clear Design Page

Show Your Part Design:

You should use graphics and text to clearly describe your Part design and where the inspiration for that part and/or design came from, if it's from any sort of previous work (iGEM project, research article, etc.).

Cite Previous Work:

If you are inspired by previous work of any kind, make sure you cite the work properly. Likewise, if you show images from research articles, make sure they are attributed properly.

Graphics Should be Clear:

When using any graphics to show your design, make sure the colors and font can be easily seen by everyone. Avoid excessive use of reds and greens in your graphics. Loopy or overly creative fonts can also make it difficult to understand an informational graphic.

Sections for Different Elements:

If your project has multiple design elements (such as an input biosensor, an output device, etc.), you should keep the design for each of those elements clearly separated, either by having multiple design pages or having clearly defined sections within one page.

Examples of Well Done Design Pages

Here are a handful of well done project design pages. These range from wet lab teams to hardware projects to software designs. These highlight the vast range of ideas and projects undertaken by iGEM teams and should highlight different ways that designs can be conveyed to the general public and to the iGEM judges.

Software design example from the 2012 Wellesley HCI team

Project Results


Make sure you post your results on you wiki (https://2016.igem.org/Team:YOUR_TEAM_NAME/Results)! It may sound like an obvious statement, but sometimes teams can forget to clearly state how their experiments ended and discuss what they concluded from that work. It's not enough to post your experimental details in your online wiki notebook - you need to have a section devoted to the results of your work on your wiki.

Recommended Components for a Clear Results Page

  • Restate the Goal: Remind the reader what the particular goal is that you're working towards in a brief phrase or sentence.
  • Summarize the Results: Quickly list or summarize your results for that goal.
  • Show Experimental Data: You will need to display the data that gave you this result. This should include some information about the experiment run or provide a link for full details about the experiment.
Show Your Controls:

Your experiments should ideally have both positive and negative controls. You need to explain the design and purpose of your controls, and you need to show the data from them. It's not enough to say you used them - if there isn't any data, then your audience doesn't know what you included in your experiments!

Links to More Detail:

Provide links that can take your reader to a page with more detail on those results, which would most likely include information on how the data was obtained and how you interpreted the results.

Examples of Well-Written Results Pages

Take a look at these example Results pages. These examples represent just a handful of teams who implemented a clear, concise Results page. It can be a difficult task and will take careful planning and hard work to execute it well. These teams all have some variation of the components given above in their pages.

Results example from the 2013 Paris Bettencourt team

Medal Criteria Checklist

Another page teams may consider having on their wikis is a Medal Criteria Checklist page. This is not one of the new standard pages, but we recommend teams create one and have it easily visible for the judges to find.


Recommended Components for a Checklist

List the Requirements:

For each medal that you are trying to achieve, re-list the requirements for that medal. It will help you remember the checklist as well as help people read through the list.

Add Checkmarks to Completed Tasks:

For each item you believe you have completed, mark it in some way. Many teams include a check mark or something similar a they go down the list of requirements.

Link to the Relevant Pages:

Within the text of each list item, if you have a page you can link out to, then include it. Some of them will not have links (ex: Register a team for iGEM in the Bronze medal requirements). For your Bronze, Silver, and/or Gold medal part requirements, you should include a link to the direct Registry page for your part.

Document Your Registry Pages:

One of the major criteria for convincing the judges that you tested your part and showed that it is functional is the data that should be posted on the part's Registry page. It is not enough to just post it on your wiki - this data must be included on your Registry pages!

Examples of Medal Criteria Pages

Here are a handful of ways that teams have highlighted their work towards the medal requirements. The chosen teams were all awarded gold medals during the competition and were chosen because they showed a completed checklist of items for their year.

Gold medal checklist from the 2014 BostonU team

Presentation

Below is some general advice for teams to consider as they start preparing their oral presentations. These are just some ideas that we hope you think about, particularly if you've never presented a talk at a conference before.

Practice, Practice, Practice:

You should practice your presentation multiple times before you arrive at the Giant Jamboree. Ideally, you should practice in front of people who are not involved with the iGEM team or project. You'll get the most honest feedback about clarity and a chance to answer real questions if you can give a departmental seminar or similar before arriving in Boston. Avoid editing your slides at the last minute / at the Jamboree, as that will only cause more stress!

Come Prepared for Questions:

Make sure to go through the presentation with your instructors and advisors (and others, if possible) with the goal of coming up with "predictable" questions. Prepare a few back-up slides that can address those questions easily. Only the team can answer questions, so make sure everyone is well versed with the methods and results.

Remain Calm During Questions:

When the judges ask you questions, try to stay calm. Many students will become defensive and sometimes aggressive in their answers since they may interpret the question as an attack on their project. Remember, it's the judges' job to ask you detailed questions about your work - they've been reading your wiki for a week, are well versed in your project already, and are excited to talk to you. If you don't understand the question they asked, don't be afraid to ask them to repeat it or ask it in another way. It's also perfectly fine to admit you don't know the answer!

Poster

Below is some general advice for teams to consider as they start preparing their poster presentations. This does not mean other methods of discussing your poster are discouraged; but rather, these are just some ideas that we hope you think about, particularly if you've never presented a poster at a conference before.

Prepare Short, Medium, and Long Poster Presentations:

Since judges and other attendees are often trying to chat with many teams during the poster sessions, you should practice three different length talks: 1 min, 3 min, and 5 min. It's very easy to get lost in the details of your project and talk with a judge or other attendee for 10 minutes (or longer!), but oftentimes for judges they don't have a lot of time to spare. Try to keep this in mind when they come to your poster.

Let People Read Your Poster:

When someone new comes up to the poster, ask them if they would like a minute or two to read the poster before you start presenting. Sometimes people are stepping closer to read the poster and other times they have already looked at it during one of the breaks and have come back to talk to you. It's polite to ask if they need some time to look things over before you being discussing your work.

Use Large Font Sizes:

You should be able to read the poster easily from a few feet away. If you need to be right in front of it to clearly read the text, the font is probably too small. A good way to check font size is this: print a copy of your poster and have it "fit to page" on a standard A4 or 8.5"x11" page, and if you can read the font clearly when you hold it out with your elbows locked, then it will probably be large enough on the poster.