As a new faculty member, I often meet staff from offices around the university. This is a fun part of being a new faculty member. I’ve been very impressed with the efficiency at which the University of Wisconsin “introduces” faculty to offices on campus whose services they may need.
This week, I met with a staff member at the Wisconsin Alumni Research Foundation (WARF), which handles patenting and licensing on campus. I was given a lab notebook after the staff member introduced me to possible services.
I have been a longtime advocate of lab notebooks (see my post here). It has been a long time since I received a lab notebook. This was a big step up from my the composition notebooks that I normally use as lab notebooks. I took a picture of the notebook below as well as instructions for using a lab notebook. It is always good to review. This one has lines for experiment witnesses.
I still use an old school lab notebook. I don’t make optimal use of my notebook, since my good ideas that start in my notebook are then revised and edited in many electronic records. Ideas are often refined in electronic documents, as the need to revise a model is often easier to do in a LaTeX document and the need to revise code is easiest to do in a programming language. I slowly and steadily fill my notebooks.
I am not sure how to best make use of lab notebooks for maintaining records given the need to collaborate with others (both in the same place around the world) and to work asynchronously with collaborators. Old school lab notebooks may not be ideal for these collaborations, where shared files must document the research contributions. Working on proposals that later become reports that then become publications basically replace a lab notebook, but this is most useful for ideas that are mature. I have found that documents in Dropbox are good for maintaining a good record of work, since Dropbox keeps old time-stamped versions of documents.
In general, I don’t have all the answers about the perfect way to maintain an electronic lab notebook with collaborators. What do you use?
Punk Rock Operations Research 
October 24th, 2013 at 10:23 am
I always keep everything I do in version control, like Git or SVN. (Git is my favorite). This provides me with a number of huge advantages:
0) Easy way to track old changes. If I deleted something, and then decide two weeks later I want to undelete it, I just go back to the old version and pick it up.
1) Easy sharing with collaborators. Collaborators want to see my history, they just check out the repository. If they want to make changes, they can do it without conflicting with anything I’m working on.
2) Particularly in Git, if I want to create different versions of the same document, I just create a different branch for each version. I do this whenever I submit papers. I have a “master” copy that I make all the text changes to, and then I create a different branch when I’m ready to submit to the journal. Then I can keep the journal formatting requirements separate from the actual text of the document. I also do this if I’m submitting a similar paper both to a journal and a prize competition, for example.
3) Tagging “landmark” versions. Every time I submit a paper to a journal, I mark that version with a tag that tells me the journal I submitted to, how many times I’ve revised the paper for that journal, and the exact date I submitted to the journal.
October 24th, 2013 at 12:37 pm
I enjoyed this:
Bill Cook sent a nice picture from his 1993 lab notebook via twitter.