| NYU Psychology | Programs | Courses | Research | Faculty | People | Events | Contacts | [Internal] |
| Pelli lab | |||||||
| Welcome | Denis Pelli | Publications | Students | Tips | Address | ||
| Style guide | Lit. search | Bugs | Art |
Style guide for scientific manuscriptsDenis Pelli Collaborating on manuscripts and graphs, I often find myself repeating the same recommendations, so perhaps it will be useful to write them down in one place, where they might be consulted by those who would like some guidance on style. Some of these comments are meant for students writing their first scientific essay, and may seem obvious to more experienced writers, but they're all applicable to all my scientific writings. These are my opinions, but I learned a lot about how to make a good figure from John Robson, Beau Watson, and Tony Movshon. 1. Convince. Don't take your audience for granted. Reading is hard. Each sentence must convince the reader to persevere. One misstep and the reader will put down your paper, probably never to return. 2. Communicate. We often talk of papers being great, as though it were an intrinsic quality independent of the readers. In fact, papers have value only to the extent that they succeed in communicating ideas to their readers, the particular audience that you are trying to reach. Understanding anything new is deucedly difficult. Thus, what strikes the author’s ear as perfect may in fact be inferior to a plainer longer exposition that is more easily understood. Polishing should heed reader comments, especially what they don't get. Interrupting the reading with questions, asking the reader to paraphrase, may reveal what the reader missed where one’s text failed to communicate. 3. Draw the figures. Most of us don't want to see the manuscript until you've included the figures (graphs, etc.), but they needn't be final data. Crude cartoons are fine. We need to see a graphical expression of what the figure is meant to communicate. (Yes, please, sketch something now.) Include the figures in the text where they're meant to be, not at the end. 4. Name it. Manuscripts should have a title and authors even if they are tentative and subject to revision. This is part of laying claim to an idea. The file should have a name closely related to the title or first author's name and should end in a number representing the draft number, e.g. channels3.doc or martelli7.doc. (Some of us have many manuscripts to keep track of.) Microsoft Word files have a much better chance of surviving transmission through email if their filename ends in .doc. (Since you're going to be emailing this file, it's best if the name has no spaces or underscores. Run the words together, or use a dash to separate them, e.g. spatialfrequency.doc, spatialFrequency.doc, or spatial-frequency.doc.) It's a good idea to mention the filename or draft number on the first page, so that one can easily tell which draft a paper copy represents. Remember to update this indication of draft number every time you create a new draft. Anyone who edits the file should increment the draft number before sending it to anyone else. 5. Help the commenter by numbering the pages and the lines. Anything you send for comment should have numbered pages. It's nice to indicate the range: Page 1 of 17. You can make it even easier for whoever is providing comments by providing line numbers, from beginning to end. In Microsoft Word, select "File:Page setup: Microsoft Word:Margins:Layout:Line numbers:Continuous." The whole paper, section by sectionTitle. One usually thinks of the title as a statement of scope or a memorable gist, inviting the reader and reviewer. However, note that when choosing what paper to cite, people will often choose a title that matches the point they are trying to justify, so that a concrete assertion may garner more citations than a generic topic. Abstract. Trying to address the broadest possible audience, make the best case you can for this being interesting and important. Tell us what you did and what you conclude. Bear in mind that most people considering whether to cite this paper will assume that all the conclusions are present in the abstract. Introduction. The main purpose of the intro is to motivate the work (i.e. convince the reader that this question is sufficiently interesting to be worth reading about), but this is also where you credit what's already been done by others, especially by potential reviewers. The intro typically takes the form of a historical review, but that's more a pretext than a purpose. The purpose is to motivate and give credit. Methods. It's important that this be correct, complete, and understandable. It should enable the reader to replicate your experiments. It can be ugly writing, repetitive and redundant, but it must be complete. How will you feel if someone fails to replicate your result uh oh! because you omitted an important detail? It is usually skipped (or lightly skimmed) in a first reading, and consulted later, to look up details. Results. Data. Graphs. The results text should have a very plain style. Just the facts, ma'm. Only minimal interpretation and comparison to other work. But do mention replication and inconsistencies (real or merely apparent) with past work. Sometimes the empirical result is more or less the conclusion of your paper. Sometimes that conclusion needs a reasoned argument, which may appear here or in discussion. Discussion. Try to give the reader the big picture. Take a step back. Try to forget your stake in this and guide the reader through your garden, noting the various considerations, positive and negative, that seem relevant. Connect this work to that of others. Even distant connections help, as readers come from various places and it always helps to understand the connection, however distant, of what's new to what's familiar. However, the meandering connections, desirable as they are, are no substitute for a tight argument that forces the reasonable reader to accept your conclusions. Ultimately that's the core of your contribution. Conclusion. Most papers published in psychology do not have a final section labeled Conclusions. My own view is that it is rarely reasonable to publish a scientific paper without a conclusion, and that it is helpful to draw attention to its presence by setting it off in its own section. The conclusion should be short and as strong as you can make it. I consider the conclusion to be the reader's reward. Acknowledgments. There's a lot of freedom here, but try to be concrete (what exactly was the contribution) and flattering. People should be glad to be thanked; if you can't word it to achieve that effect then don't bring it up. References. It is almost impossible to type references by hand without introducing errors. This is something that computers are good at. Use Endnote (available for Mac and Windows). Endnote can download references to articles directly from PubMed (the National Library of Medicine) and PsycINFO and can download references to books from the Library of Congress and most university libraries, including NYU. Endnote will format your references in whatever style you like. (For PsycINFO you'll need an NYU-specific Endnote connection file.) The resulting reference list is very accurate, and can optionally include a link to the PubMed abstract. GraphicsFigures. All text within a figure should be in Helvetica, including the axis labels, etc. (The figure caption should be in 10 point Helvetica, to help distinguish it from the rest of your text.) Don't use bold. Capitalize only the first letter, as in a sentence, e.g. Spatial frequency (c/deg). In general, remember that the graph is meant to express the data, and that the data themselves should draw the most attention. The rest of the stuff (scales, labels, legends) should recede into the background, not compete for attention. I usually like to represent data as points and the model as a solid line. We usually use Kaleidagraph (available for Mac and Windows). We typically use logarithmic scaling. It's not an absolute rule, but I find that papers are easier to follow if a log unit has a consistent length (e.g. 1 inch) within a graph (horizontal vs. vertical) and throughout the paper. In Kaleidagraph, you set the length of the X and Y axes by selecting Plot:Set Plot Size:Axis size:. If you do display error bars, omit the distracting hats at the ends of the error bars. When you send the final graphics file to the publisher, vector graphics are preferable to pixelated images, because they look better and take up less space in the final PDF file for your published paper. Kaleidagraph's Export options are poor, but you can copy to clipboard a PICT with Postscript, and, if you're using Mac OS X or have Acrobat installed, then you can Print to PDF. The latter is the best way to produce files for production of your article by the publisher. When you email any graphics file, the filename extension matters: .jpg, .gif, .pdf. For any other file I suggest that you enclose the files in an archive (e.g. zip or stuffit) to protect the file resources, which will otherwise be stripped in the course of emailing. Helvetica. As of July 2007 none of the available versions of Helvetica are adequate for scientific use. The Helvetica provided by Apple with Mac OS X lacks italics. (You need italic to correctly represent mathematical variables. Some programs, e.g. Word, will let you fake an italic, by slanting, but Adobe Illustrator won't. ) The versions of Helvetica sold by Adobe and Linotype lack unicode support. Unicode extends ASCII to a 16-bit code, allowing us to specify any character shape (glyph) independent of the font. For scientific text this is very helpful because it allows you to include Greek symbols without changing font. However, unicode is still quite new and neither Adobe's nor Linotype's Helvetica supports unicode. Ironically, Apple's Helvetica does, but the lack of italics rules it out. Use Arial instead. Arial. The full history is complicated, but, in effect, Microsoft created Arial by copying Helvetica, to save money. The only difference
I notice is that the "1" in Arial has a longer diagonal line. Type
designers notice other subtle differences.
You
can test your
ability to distinguish them. (Thanks to Hannes Famira for these links.) The
version of Arial provided by Apple in Mac OS X lacks unicode support. However,
Microsoft Office comes with a better version of Arial, which does support unicode
and includes the Greek characters. So, on your Mac OS X computer, you should
delete: Heading and labels. With others, I helped convince Journal of Vision to adopt sentence-style capitalization for all headings and figure labels. Capitalize only the first letter of the first word. Numbers. When presenting numbers less than one, the decimal point should always be “covered,” so you should replace “.1” by “0.1”. The problem is that the printed decimal point may be so tiny as to disappear. If you put a leading zero in front of it, the reader will still know that it's there. Units. Physical measures, e.g. "10 ms", should always include a space between the number and the units. Equations. Don't confuse mathematics (equations) with computer programming (assignment statements); they have different rules. Here are my suggestions for equations. Use MathType (available for Mac and Windows). Math variables, like E and x,
should be italic and only one letter long. Be friendly to your variables,
don't set them off by commas. Don't use “*” to mean multiply.
Don't use multi-letter variable names; long names are common in computer
programming but confusing in math, where multiplication is implicit,
as in ax. However, you can use a long text subscript, as in Lbackground.
Subscripts that are not variables should not be in italic, eg crms
and Lbackground.
Functions, like sin and log, are not variables and should not be italic.
Avoid the temptation of indicating an approximate value by “~”, as most journals print that symbol almost indistinguishably from the minus sign “ ”, which is likely to confuse your readers. Instead of “~” use “about”, “roughly”, “approximately”,
or the approximately equal symbol “ Don't underline; reserve that for links. Underlining is a proof reader's mark indicating italic, which was incorporated into typewriters because they couldn't do italics. It was not meant to appear in printed material. Some journals allow it, but I think it looks bad. In any event, it has become a fairly standard way of indicating a URL (a web link), so I suggest restricting it to that role. I also suggest never using the underscore character “_”, especially in filenames, because if you make that text a link then it will be underlined, and an underlined underscore is indistinguishable from a space. Technical tip from Kaleidagraph support: Using font characters as markers. You can't modify the markers that are built into KaleidaGraph, but you can add text error bars to your plot. Text error bars are normally used to annotate the points in the plot. You could create a Line plot, hide the original markers, and add text error bars to the plot. As an example, you might create a text column with the letter a in each row. Once you add this column as text error bars, you can double-click the text and change the font to Zapf Dingbats or some other font that has different symbols in it. The manual and help file contain information on adding text error bars to a plot. To use them as markers, you would want to add them as X error bars. You would also want to make them single-sided and have the text centered (using the Center Text option). Also see: Updated |