Line 350: | Line 350: | ||
<div class="highlight gray"> | <div class="highlight gray"> | ||
<h5>Judging Sessions - Answering Questions:</h5> | <h5>Judging Sessions - Answering Questions:</h5> | ||
− | <p> | + | <p> Remember, it's the judges' job to ask you detailed questions about your work - they've been reading your wiki for two weeks, watched your presentation video, 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! |
− | + | ||
− | + | ||
</p> | </p> | ||
</div></div> | </div></div> |
Latest revision as of 19:57, 26 October 2021
Telling Your Story
On this page you will find: Tips for Working on the Wiki, Project Overview, Project Design, Medal Criteria Checklist, Presentation Video and Judging Sessions, and Poster.
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 2021 season. Telling your story in a clear and concise way is challenging, but well worth the effort in the end.
For the Public
Remember, your wiki is the public-facing representation of your project! This can also be an incredibly useful resource for fundraising. 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.
![](https://2013.igem.org/wiki/images/9/90/Overview1.png)
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.
![](https://2015.igem.org/wiki/images/thumb/f/fd/SynFlo_Wellesley.png/800px-SynFlo_Wellesley.png)
Software design example from the 2012 Wellesley HCI team
Project Results
Make sure you post your results on you wiki (https://2021.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.
![](https://2015.igem.org/wiki/images/6/60/Screen_shot_2015-06-05_at_4.34.46_PM.png)
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.
![](https://2015.igem.org/wiki/images/thumb/c/c9/2014_BU_Gold_medal_reqs.png/800px-2014_BU_Gold_medal_reqs.png)
Gold medal checklist from the 2014 BostonU team
Presentation Videos and Judging Sessions
Below is some general advice for teams to consider as they start preparing their Presentation Videos and getting ready for their Judging Sessions at the virtual Giant Jamboree. These are just some ideas that we hope you think about, particularly if you've never presented a talk at a conference before.
Presentation Videos:
The presentation video should be clear, engaging, and communicate your project to a broad audience. The focus of evaluation will be on the technical content and how the scientific details of your project are communicated. This video should focus on clear, concise, and precise communication of technical aspects of your project (project design, results and data analysis, and conclusions). Teams should review the Deliverables page for guidelines and examples of great Video Presentations (button below).
Judging Sessions - Project Overview:
During the Judging Session, you will be given 5 minutes at the start of the session to provide an overview of your project. You should practice this overview and decide on the format well ahead of time. You will be able to share your screen to show slides, a video, wiki pages, or other material.
Remember that only student team members and student team leaders are allowed to present materials and answer questions during the Judging Session!
Judging Sessions - Answering Questions:
Remember, it's the judges' job to ask you detailed questions about your work - they've been reading your wiki for two weeks, watched your presentation video, 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
Teams are no longer required to produce a poster for the iGEM 2021 Competition. Please email traci [AT] igem [DOT] org if you have questions!
If you are still making a poster for Meetups or other activities, 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 judges 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 begin 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.