meta data for this page
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
general:dokuwiki:how2document [2019/06/11 14:15] – [Additional information] ingo | general:dokuwiki:how2document [2022/12/20 09:30] (current) – [References] ingo | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
- | ===== Necessary information ===== | + | Most practical modules |
- | Project documentation is essential when working | + | |
- | <figure docucont> | + | <WRAP important>< |
- | {{: | + | ===== Objective ===== |
- | <caption>< | + | Before writing a lab protocol, you should ask yourself not only //why// your are writing a lab protocol, but much more //what you want to achieve// with the lab protocol. The answer is considerably simple: You write the lab protocol for |
- | </ | + | * yourself. It should bring you in the position to easily repeat your analysis - or parts of it - somewhen in the future, and probably at a time point where you can no longer do it from the back of your head((since you have forgotten about all the details)) |
- | </figure> | + | * for any other person that comes after you, such that this person has a chance to understand |
+ | * what you did | ||
+ | * why you did it | ||
+ | * and how you did it | ||
+ | <wrap important> | ||
- | ===== Project report | + | ===== How to write a lab protocol |
- | For successfully completing the module, you will have to submit | + | It happens often that people |
- | * a meaningful introduction which specifies | + | - A protocol is a scientific text, and thus the [[howto: |
- | * a comprehensive listing | + | - A protocol is typically written for a short term project. Its focus is more on the technical part and the results, and less on answering a particular scientific question((It is, thus ok to keep introduction and discussion concise)) |
- | * relevant software together | + | - A protocol is meant to provide< |
- | * data sources together when they have been last accessed (e.g. databases) | + | - all data |
- | * relevant parameter settings | + | - all programs |
- | * list of analysed species, if necessary | + | - all analysis steps |
- | * A comprehensive presentation of your results. Make sure that the reader understands what question | + | that are required |
- | * A discussion | + | Follow |
+ | |||
+ | <fs 1.5em>< | ||
+ | ===== Some additional points to consider ===== | ||
+ | |||
+ | Below, we have compiled | ||
+ | ==== Structure of the protocol ===== | ||
+ | Try sticking to the standard structure< | ||
+ | * Introduction | ||
+ | * Material & Methods | ||
+ | * Results | ||
+ | * Discussion | ||
+ | * References | ||
+ | <WRAP important> | ||
+ | |||
+ | ==== Figures ==== | ||
+ | <wrap important></ | ||
+ | |||
+ | Each figure... | ||
+ | * has a figure number. And figures have to be numbered in the order they are mentioned in the text | ||
+ | * has to be mentioned in the text | ||
+ | * has a short, informative title | ||
+ | * has a description that reflects the message | ||
+ | * should be interpretable on its own. It is generally not optimal | ||
+ | |||
+ | <wrap important></ | ||
+ | * Screenshots as figures can be ok, but only when the image quality is sufficiently high. | ||
+ | * make sure that the font and the font size is uniform across the figures. Text must be <fs 0.1 em> | ||
+ | | ||
+ | |||
+ | ==== Tables ==== | ||
+ | Like with figures, think about the information that should be provided with a table | ||
+ | * tables | ||
+ | * each table has to be mentioned in the text | ||
+ | * each table has an informative title. Table columns can be explained in the table footnotes | ||
+ | * avoid landscape tables | ||
+ | * avoid tables that extend over more than one page. Consider placing large tables into the supplement | ||
+ | * don't use vertical lines to delimit table columns. Horizontal lines to delimit rows are ok, though | ||
+ | |||
+ | ==== Methods ==== | ||
+ | * provide references for the programs | ||
+ | |||
+ | ==== References ==== | ||
+ | <wrap important></ | ||
+ | * Make sure that references in the text, and your bibliography is correctly and consistently formatted. We prefer the //author, year// format for in-text citations over numbers. | ||
+ | You can read more about how to cite in this document provided by the University | ||
+ | ==== Abbreviations ==== | ||
+ | Abbreviations, that cannot safely be considered common knowledge, have to be explicitly introduced. | ||
+ | * For example | ||
+ | * Species names have to be given in full length, before you start abbreviating them. For example you should write: "(...) we extracted all ribosome biogenesis factors from yeast (// | ||
+ | |||
+ | ==== Spelling ==== | ||
+ | Most editors provide | ||
+ | |||
+ | ==== Headings ==== | ||
+ | Headings should be concise and informative. Something like ‘Getting an idea (of) how to use HaMStR…’ should be avoided. This could be reformulated to ‘Establishing the HaMStR Workflow for …' | ||
+ | |||
+ | ==== Miscellaneous ==== | ||
+ | * Use standards whenever possible | ||
+ | * briefly introduce relevant methods such that you - as well as any other person - comes into the position to understand what kind of analysis you are actually doing. | ||
+ | * Avoid lab jargon. For example, //to blast// is not the appropriate verb for // | ||
+ | * Avoid group-internal abbreviations such as //DROME// as an abbreviation for // | ||
+ | * Datensets | ||
+ | * Introduce data sets that you use in your analysis in the Materials section, and make sure to explain where the data is located | ||
- | You will find some general guidelines for writing a project report, or in general scientific text here | ||
- | * [[https:// | ||
- | * How to write scientific text | ||