Apologies to a commenter!

January 25, 2010 by z_californianus · Leave a Comment
Filed under: Uncategorized 

A commenter had left a kind note thanking us for our work on the Darwin Manuscripts Project. In my enthusiasm for deleting spam, I accidently deleted the comment. I wasn’t able to notice who the comment was from. My apologies! Thank you for the words of support and appreciation.

The mentor’s role in improving students’ scientific writing

January 25, 2010 by z_californianus · Leave a Comment
Filed under: Science writing 

Some of my friends on twitter have been talking about how to become a better scientific writer, that is, how to write about their research for publication in professional outlets such as peer-reviewed journals and grant proposals. @scientistlady directed me to a page at the Bio Careers site entitled “Skills To Help You Become A Better Scientific Editor.” The posting is written by Chris Gunter, also known as @girlscientist. Chris is an excellent source of information on this topic, having served in a variety of leadership positions in research institutions and scientific publications including Science and Nature.

Chris’ advice is eminently sound: read lots, join a journal club, summarize papers about new research and keep a file of the summaries. Like most good advice about how to improve one’s writing, this advice is sensible and easy to follow, and doing so will take time and effort. There is one bit of advice, however, which I think requires attention: “Ask your mentor to let you help review grant applications or manuscripts.”

Chances are, your PI receives referee requests, All. The. Time. It’s also likely they could use some help. Journal editors are generally just fine with students or postdocs assisting with (let’s be honest, this often means writing) reviews of papers, as long as the editor is notified that you have assisted, and you agree to keep the paper completely confidential. Many journals also mail back the anonymized referee reports after the decision has been made, so you can see how your report stacked up against the others.

Some of the best mentors I have known have conducted mini-study sections for their labs, gathering the graduate students together and parsing out a number of grants among them, then reconvening for detailed summaries. Again, confidentiality is crucial, but this is another great way to learn.

I agree that graduate students should offer their mentors help reading and refereeing papers and grant proposals, and I would think (and hope!) that most mentors would give their students a chance to help in this way. Nonetheless, I think that mentors should approach this as a teaching task that’s taken seriously. The mentor should read the paper or proposal as well, think about what he or she would say in a review, and take the opportunity to have a tutorial session about the proposal or manuscript with the student. Reviewing a paper or proposal takes a significant amount of subject-area knowledge and understanding of the field which most students are not likely to have. The aim of a reviewer is not just to evaluate the methods and conclusions in the paper or proposal, but to evaluate the work’s value as a contribution to advancing the field. Only someone with experience and insight greater in a discipline than what someone just starting out can be expected to have is in a position to evaluate work from this perspective. If mentor and student work on the review together, taking the time to improve the prose style as well as refine its argumentative strategy, the student will benefit enormously. At the same time, the mentor’s direct supervision assures that the review meets a high standard for quality and relevance.

My comments come from a few years’ experience as an editor at Evolution: Education & Outreach, during which time I have come to appreciate the importance of reviews which are able to position the work for review in relation to the central questions of the discipline in which they are intended to make a contribution.

If a PI or mentor were to take my advice, offering students the chance to help with reviews will most likely result in more work for him- or her-self, not less. Nonetheless, the quality of the student’s work will improve in the short and long term, and the quality of his or her reviews will, as well. From a purely self-interested point of view, this will benefit the mentor. He or she who will come to be known as someone who can be trusted to generate insight and to train graduate students who can do so.

OmniOutliner Pro = OmniExporter Pro

January 18, 2010 by z_californianus · 1 Comment
Filed under: Tips and tricks 

The institution at which I teach requires faculty to submit copies of our syllabi at the start of each semester. Let me put the ethics and utility of requiring that to one side so that I can share a little about how I’ve produced documents which comply with that request. Omnioutliner Pro has proved invaluable. It took me a long time—longer than I’d expect, given that Omnioutliner Pro is reasonably lightweight and well-designed—and I hope this post will save someone else the trouble.

I always find the process of creating the table in HMTL containing links to the syllabus, course readings, etc., etc. to be agonizing. OmniOutliner Pro is good for this, too.

WhenI have a little more time, I’ll post some samples of what I came up with. I’d also like to fill in some more links on this page.

OmniOutliner to Latex & .docx

I use LaTeX for my syllabi (as well as any other writing I do), and the administration provides us with a template in MS Word format, more precisely, .doc format. That sets a high bar for compliance with the College requirements, because as is well-known, exchange between Word and LaTeX formats is notoriously difficult. The LaTeX community relies on the late Eitan M. Gurari’s TeX4ht utilities for converting LaTeX to HTML and other formats, including the OpenDocument format used by the OpenOffice.org office suite. This creates a clear pathway.

  1. Write the syllabus as usual in LaTeX.
  2. Process the typeset syllabus with TeX4ht, set to output to the OpenDocument format. Those that don’t like the command line can use SimpleTeX4ht.
  3. Open the resulting document in OpenOffice.org.
  4. Cut and paste the text into the template. I use Pages for the template, which is a .doc document.

I followed this pathway to convert most of each of my syllabi into a format I which could be inserted directly into a document in the .doc format. Nonetheless, the syllabus has to have more than just the list of requirements, policies, etc., etc. There is a complicated table with the schedule of readings and assignments. The first semester in which I had to turn in the syllabus in the .doc format, I took a screen shot of a PDF copy of my syllabus and dropped it into the template. I didn’t want to do this a second time around. The screen shots were an odd size, and it was difficult to maintain the placement of the text. Why I care about the layout of this copy of the syllabus is anyone’s guess; most probably, it will be used primarily to document the College’s compliance with accreditation requirements, rather than being an object of serious study. I suppose it may as well look good for that. In any case, this is where OmniOutliner Professional came in handy. There were two conversions it performed, together with another useful command-line tool, csv2latex.

I found csv2latex by way of Google.com. It seems that there are two scripts of that name.

  1. An older csv2latex, the latest version of which seems to be 0.16, at http://herewe.servebeer.com/csv2latex/. This is the script I used. I had to build it; the source code is available at http://herewe.servebeer.com/csv2latex/releases/?M=D. On OS 10.6 (Snow Leopard), it compiled without a hitch after invoking make csv2latex at the command line.
  2. A newer csv2latex, on CTAN, at http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=csv2latex. It’s maintained by a frequent contributor to the tex-on-osx mailing list, Alan Munn. The documentation for this at CTAN reads as follows:

The package provides a Ruby script–Applescript combination that allows the user to cut and paste spreadsheet tables (e.g., from Excel, OpenOffice Calc, iWork, Numbers, etc.) into a LaTeX source file in various popular LaTeX table formats: plain tables, booktabs, longtable, and raw cells.  The package is designed to work with TeXShop, and can be used with other Mac editors that support Applescript.

I used the first of these two scripts.

[I take this moment to acknowledge the cute domain name http://herewe.servebeer, where there are some other interesting software projects.]

Note that you can definitely spend hours getting absolutely nothing done and becoming, well, frustrated, if you repeatedly enter

cvs

when you should be typing

csv.

Nothing like that happened to me, of course.

OmniOutliner to LaTeX

  1. Create a table in OmniOutliner with the following columns: week number, date of each week, readings and assignments. OmniOutliner exports csv in a peculiar way. The contents of each cell are enclosed in double quotes, precisely the kind that LaTeX doesn’t like. Likewise, there is a “Note” column in OmniOutliner which apparently cannot be deleted. When I get the time I will write a “de-OmniOutliner” script to remove these “extra” bits.
  2. Export the table as csv from OmniOutliner.
  3. Process the resulting file with csv2latex.
  4. A LaTeX article class document will result, containing the table only.
  5. Cut and paste away. . .

Some people might ask, Why not just use OmniOutliner Pro’s option to export to LaTeX? The answer is that this exports your table as an article-class document, not as a LaTeX table. Only the leftmost column is output into LaTeX. This is useful if you are using OmniOutliner to create a draft of a document or an outline. Rows can be output as section headings, body text, etc.

OmniOutliner to .docx

  1. Create a table in OmniOutliner as described above.
  2. Export to .docx format. [OmniOutliner Pro does not export to .doc format.]
  3. Open the new document in OpenOffice.org or Pages.
  4. Cut and paste away . . .

OmniOutliner to HTML

This was not as straightforward as I had thought it would be. The HTML export option created HTML code for a table only containing the leftmost column of my OmniOutliner table. The export option entitled “HTML (active)” output the full table. According to the OmniOutliner documentation, this is supposed to produce a table in which the rows can be hidden and expanded. It also created widgets such as triangles and squares which were to be used as “bullets.” All I got was HTML code for a static table with no bullets, although it did have every cell in the table I had created in OmniOutliner. I opened it in Amaya, which verified it as compliant. So I expect I will be cutting-and-pasting this into my course web page, which I will probably end up composing entirely using Amaya.

Next Page »